E-commerce
Integração de Sistemas
Startups
APIs
Produto Digital

电子商务和应用程序之间的集成:初创公司在实施之前需要决定什么

将电子商务和应用程序集成是一个架构和业务决策,然后才是代码决策。

电子商务和应用程序之间的集成:初创公司在实施之前需要决定什么

大多数在线销售的初创公司以错误的方式进入应用程序。首先,商店诞生,通常在一些现成的平台上,然后应用程序出现,作为对投资者问题或对推出其应用程序的竞争对手的回应。当这种情况发生时,集成就变成了拼凑而成:两个世界需要使用相同的语言,但却是为不同的对话而构建的。

这不是技术问题。这是一个决策太晚的问题。将电子商务和应用程序集成是一种架构选择,会产生直接的业务成本:它会影响交付速度、客户体验以及您以后改变主意的能力。对于初创公司来说,后来改变主意就成功了一半。

本文是为那些处于这一阶段的人准备的:他们已经在网络上拥有了吸引力,即将投资移动领域,并且希望避免陷入构建两种互相讨厌的产品的陷阱。

为什么集成的决定性比看上去的要大

客户看不到你的架构。他看到了一致性。如果他在午餐时用手机将商品添加到购物车,并在晚上在笔记本电脑上打开网站,他希望发现购物车完好无损。如果促销价格出现在应用程序中,则在网站结账时不会接受不同的价格。

这些期望看似微不足道,但只有当两个渠道背后都有单一的事实来源时,它们才能得到满足。当应用程序和电子商务维护目录、库存、价格和会话的单独副本时,分歧只是时间问题。在数字零售、成本转换和信任方面存在分歧。

这里的论点很简单:应用程序不应该是第二个系统,它应该是同一系统的第二个客户端。 业务的核心、目录、订单、支付、库存、用户身份都位于一个地方,由 API 公开。网络和移动设备只是界面。

创始决策:无头还是整体

在编写任何集成之前,初创公司需要决定其核心的格式。有两条诚实的道路。

第一个是继续使用封闭的电子商务平台并通过 API 消费其提供的产品。当应用程序本质上是一个带有结账功能的店面时,它一开始会更便宜,并且完全有效。 Shopify、VTEX 或 Nuvemshop 等平台公开了合理的 API,使您无需从头开始重建支付、反欺诈和订单管理。

第二种是采用无头架构:电子商务作为商务后端,没有耦合的前端,网站和应用程序都使用相同的 API。它提供了更多的自由并为增长奠定了基础,但需要更多的工程成熟度。

对于大多数早期创业公司来说,最昂贵的错误不是选择错误,而是没有同时选择并推动两者。根据一个问题做出决定:您的产品在购买体验或购买后对数据的处理方面是否具有差异化?如果您有经验,请投资 headless。如果您想继续发展,请让平台来处理商务,并将您的工程重点放在其差异化的地方。

真正需要同步的内容

并非所有事情都需要实时。把一切都视为关键是无声地烧毁跑道。值得分开。

目录和价格可以容忍一定的滞后,只要它受到控制,每个事件或每个短窗口的同步通常就足够了。库存更加敏感:销售不存在的产品会导致应用商店取消、退款和差评。购物车、会话和用户身份需要真正统一,因为这是客户意识到他们正在使用“同一家公司”的地方。

付款值得有自己的段落。不要在应用程序和网络之间重复支付逻辑。集中在后端,使用相同的提供商和相同的反欺诈流程。价差支付是一种成为金融事件的技术债务。

客户身份和数据:LGPD 的用武之地

这里的对话不再只是关于建筑。当应用程序和电子商务共享身份时,您将整合来自两个渠道的同一持有者的个人数据,[LGPD0 会严肃对待这一点。

对于初创公司来说,在产品与市场契合之前保留隐私是很诱人的。这是一种虚假的经济。从一开始就定义数据所在的位置、谁访问数据、收集数据的法律依据以及客户如何请求删除,现在比在 ANPD 通知或客户要求其权利的压力下重建所有内容要便宜。

三个实际的决定可以让你以后免去很多痛苦。维护单一客户记录,而不是每个渠道一个。以可追溯的方式记录营销同意,因为应用程序打开了推送等新渠道,并且网络同意不会自动覆盖移动同意。并像对待敏感凭证一样谨慎对待您的应用程序会话令牌,因为它是支付和地址数据的网关。

从小事做起,但要从正确的角度开始

初创公司没有能力在验证之前构建完美的集成。解决方案不是削减架构,而是削减范围。

第一个健康的削减:应用程序使用目录并通过现有的电子商务 API 进行结帐,重复使用相同的登录名和相同的支付提供商,并且不会尝试同步除必需品之外的任何内容。推荐、忠诚度计划和分段推送等功能稍后会在已经真正集成的基础上推出。

这里常见的错误是使用并行后端快速启动应用程序“只是为了 [MVP1]”,并承诺稍后统一。这种“后来”很少出现,当它出现时,它会发现两个系统之间存在数据冲突和真实用户。迁移活跃客户是初创公司可以进行的风险最高的操作之一。

整合不良的隐形成本

值得坦率地指出风险。糟糕的整合不会彻底失败,它会慢慢地流失利润。出现在一个通道上而在另一通道上消失的请求。黑色星期五股票销量翻倍。营销团队在应用程序中发布且电子商务无法识别的促销活动。每一个这样的事件都会消耗一个小团队的时间,而这个团队应该构建产品的下一步。

还有治理成本。两个客户数据库意味着两个地方可以响应删除请求、两个地方可以泄露、两次审计。对于那些梦想被收购或筹集更大资金的人来说,技术尽职调查正是针对这一点的。

结束

电子商务和应用程序的集成并不是连接两种产品。它认识到只有一种产品,即您的业务,而网络和移动设备是它的窗口。早期内化这一点的初创公司在成长过程中无需在每个阶段重写整个体系。

值得在下一次产品会议上提出的问题不是“我们如何让应用程序与商店对话”,而是“我们的事实来源是什么以及还有谁需要使用它”。首先回答这个问题,集成就不再是补丁,而是成为基础。

如果您的初创公司正处于网络和移动之间的交叉点,并且尚未有意决定架构,那么在编写第一个集成线之前值得讨论。博客上还有其他有关 API、[LGPD2´ 和产品可扩展性的文本,可以帮助您进行推理。

另请阅读

  • [电商反欺诈:每个初创企业在规模化之前都需要的分步指南3
  • 【电商与APP融合:如何在不中断运营的情况下在企业落地44
  • 【应用内在线支付:每个初创公司在收费前需要决定什么55
  • [面向初创公司的应用程序:扩展之前真正重要的事项清单6
  • 【全渠道电商:渠道整合指南7
  • 【电商与App融合:渠道同步8