话题公司 › 58同城

公司:58同城

关联话题: 天鹅到家

58同城(NYSE:WUBA),简称58,是一家位于中国北京市的生活服务及分类信息网站,以在地服务为主,举凡租房、招聘、交友、水电、二手交易等等,由北京五八信息技术有限公司拥有,创始人是姚劲波,成立于2005年12月12日。该网站是中文最大的生活信息网站,该网站的口号是“一个神奇的网站”。

多平台消息推送服务的实践

在我们实际业务中,多个服务常常需要向用户发送不同形式的消息,包括但不限于企业微信、飞书、短信、邮件、微信通知和手机应用通知等。如果每个服务都独立开发一套消息发送代码,这将导致维护难度大、错误率高,效率极低。为解决这一问题,我们开发了信鸽平台。

转化率翻倍秘诀:打造用户信任三角(上)

在本地服务行业,用户与平台之间的“信任”关系扮演着至关重要的角色,直接影响交易、留存、忠诚度、口碑传播等关键指标的转化情况。本文将以设计师的视角深入探讨如何提升用户对58到家(本地服务业务)的信任,从而构建一个稳固的“信任三角”。

浏览器如何运行一段JavaScript代码

邀请大家一起从浏览器的角度来看一下一段JavaScript代码到底是如何执行的。

图像搜索的新纪元:Milvus与CLIP模型相伴的搜图引擎

本文介绍了Milvus的技术原理和对CLIP模型的应用。通过将Milvus和CLIP相结合,我们可以构建出一种强大的搜图引擎,使用户能够通过文本描述或者上传的图片进行准确的图像搜索。

拉流端直播xgplayer使用经验

为了强化官方验的心智,平台要做一版新的质检直播间...

用设计点亮一座城,58设计愿天下无诈

设计师们成功推出了一项重庆的多巴胺公交站台项目,受到市民们的喜爱和认可。他们希望通过设计影响大家,让世界免于诈骗的困扰。这一项目在抖音等平台上引起了热议,总播放量达到了2300万+。

一文读懂转转通用筛选组件

更新功能中使用了Map数据结构来提升更新效率,并解决了筛选组件与搜索框组件之间的联动问题。组件还提供了自动吸顶与滚动功能,可以根据参数控制滚动的距离和吸顶效果。公共筛选组件已经覆盖了80%的卖场筛选场景页面,线上运行稳定且提升了交互体验。然而,在复杂业务场景中,复用组件时需要注意数据层的实例化和组件之间的交互行为异常。

突破局限!广告计费系统高可用升级之路

在现代业务中,服务稳定性和高可用性起着至关重要的作用,特别是在广告计费业务中,高可用性尤为重要。本文主要介绍了广告计费系统的功能和升级背景,并针对高可用性进行了升级和多个改进,为提高系统的稳定性和可用性提供了思路。

MQ消息在自动化CASE中的应用

从代码层面来说,订单作为数据流,理论上直接调订单服务的接口就能完成订单状态的变更,实际上涉及实物的订单,线上线下会有联动关系,订单状态的变更依赖实物的流转状态。

从业务层面来说,B2C业务作为公司核心业务之一,订单的服务对B2C流程做了很多针对性处理,日常需求的改动时,如果能够自动化的回归B2C流程的正逆向流程,对于QA来说会起到事半功倍的效果。

B2C业务流程举例说明,用户在APP下单支付后,订单服务会调用仓储服务的接口,创建出库单,质检仓发货成功后,对外发送MQ消息,订单服务收到MQ消息后,才会修改订单状态为【已发货】状态,用户签收后,订单收到物流签收消息,状态变更为【交易成功】。

关联图谱在转转风控的实践

关联图谱构建了“关系”反作弊的桥梁,实现了点、线、面全方位的风险识别。

微前端时代:打造高效、灵活的前端开发体系

系统化地介绍微前端及其核心技术,并介绍了什么是微前端以及为什么我们需要它。我们还讨论了在众多微前端框架中如何选择适合自己系统的框架,并分享了一些业界使用微前端的实践案例。

多任务多场景问题解决方案与实践

多场景是用户体验服务的多种途径,多任务是系统为综合衡量用户体验而建模的多个目标,多场景和多任务都是算法场景面临的重要问题,转转的业务发展模式同时还带来了多业务的问题,当模型面对如此复杂的问题,看业界如何求解,转转怎样实践?

付费会员场景下的设计机会点挖掘

设计师的价值就是解决问题,对业务支撑是基线,对业务赋能是增量。从更好的效果、更高的效率等角度寻找设计赋能机会点~

安居客房产在工具构造上的提效实践

在前端低代码技术实现上引入了公司部分成熟的技术框架,后端低代码技术实现上结合公司的业务体系定制不同规则组件和规则处理引擎。

规则引擎与商业CRM的完美邂逅:将智能决策融入商业扩展

规则引擎是提升业务规则管理效率的有效利器,什么是规则引擎,什么场景适合用规则引擎,如何在生产实践中落地,这些如果有疑问,这篇文章将给你逐一解惑。用实际业务场景遇到的问题为样例,带你全面了解规则引擎实战的点点滴滴。

多数据库测试提效探索

随着互联网的快速发展,传统的单体系统架构已不能满足海量用户的需求。系统的架构大致经历了:单体应用架构—>垂直应用架构—>分布式架构—>SOA架构—>微服务架构的演变。随着架构的演变以及日益增大的流量规模,底层的数据库/表的数量也越来越多,越来越细化。

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-11-28 13:34
浙ICP备14020137号-1 $bản đồ khách truy cập$