平台与迁移
如何在不损失收入的情况下将电商商店迁移到新平台？
更新于
电商迁移会在三个方面损失收入，而店面不是其中之一。URL结构变化会破坏累积的搜索资产，除非每个旧路径都通过301重定向到其新等效路径。存储的支付凭证通常无法在平台之间移动，这迫使活跃订阅者重新输入银行卡信息，并永久失去一部分订阅者。而订阅状态——下一次账单日期、套餐、折扣历史——是最难协调的数据。请安排迁移顺序，确保在任何切换之前，这些方面都已得到验证。
主题是每个人都计划的部分，也是很少出问题的部分。
平台迁移项目将大部分时间分配给重建店面，因为这是可见的工作，也是利益相关者有意见的部分。这也是犯错成本低的部分：一个看起来有问题的页面会在当天被发现并修复。
昂贵的失败是无声的。一个有漏洞的重定向地图不会报错；流量在接下来的几周内会简单地下降，等到有人调查时，原因已经变得模糊不清。无法扣款的订阅者不会抱怨；他们会流失。这些是需要保护的东西。
URL：重定向地图就是迁移本身
每一个曾经获得链接或排名的URL，都必须永久解析到其最接近的等效URL。不要重定向到主页——重定向到主页会被视为软404，并且不传递任何权重。
从数据而不是站点地图构建地图：导出过去一年中所有获得自然流量或有入站链接的URL，包括分页集合、筛选后的类别路径、已下架的产品页面和旧博客文章。已下架的产品应重定向到其类别或替代品，而不是死胡同。
切换后，通过抓取旧URL列表并确认301重定向到200状态码来验证。这是唯一必须自动化的迁移检查，因为手动抽样可能会通过，而数百个长尾路径却会失败。
支付凭证：在承诺之前确定可移植性
这是最常决定迁移是否可行的限制条件，并且需要在签订合同之前而不是在规划期间得到答案。
存储的银行卡是否可以移动取决于谁持有令牌。如果您的支付凭证存储在您自己的支付处理器账户中，它们可能可移植，或者支付处理器可能支持直接迁移。如果它们存储在平台或应用供应商处，它们通常无法离开。
当令牌无法移动时，每个活跃订阅者都必须重新输入银行卡信息。将其视为一个具有实际损失率的收入事件来规划，而不是一个沟通任务，并将其作为一系列活动来运行，提供无需登录的自助更新路径。如果您拥有庞大的订阅者基础且令牌不可移植，那么这种损失可能超过迁移的全部收益。
一个围绕不可逆转因素构建的序列
安排工作顺序，确保每个不可逆转的步骤之前都有其将成功的证明。
- 1. 以书面形式与两个支付处理器确认令牌可移植性。如果令牌无法移动，请模拟订阅者损失并重新决定是否进行迁移。
- 2. 导出并核对商品目录、客户、订单和订阅状态。核对意味着数量和总计匹配，而不是导入报告成功。
- 3. 根据流量和链接数据构建重定向地图。针对完整的旧URL列表自动化验证。
- 4. 使用生产数据并行运行两个系统，新系统不承载实时流量。比较相同输入下的订单总额、税费、运费和订阅的下一次账单日期。
- 5. 切换店面流量。连续四周每天观察抓取错误和自然会话——这就是重定向漏洞浮出水面的时候。
- 6. 在店面被证明稳定后，最后迁移账单系统。同时迁移两者意味着任何一个系统出现故障都需要针对两个变化进行诊断。
平台可以承担的工作
PlatformDTC通过销售主导而非自助服务的方式帮助迁移品牌入驻，这是上述所有因素的有意结果：重定向地图、凭证问题和订阅核对不是注册流程可以承担的任务，在这三个方面出错的迁移对品牌造成的损害比不迁移更大。
常见问题
- 电商平台迁移需要多长时间？
- 店面通常耗时最短。时间线主要由数据核对和支付凭证问题决定，拥有大量活跃订阅者和不可移植令牌的迁移项目，与仅移动商品目录的项目相比，是一个不同且耗时更长的项目。
- 迁移时我会失去SEO排名吗？
- 仅当您的重定向地图存在漏洞时。一个完整、永久、一对一的重定向地图可以保留大部分累积的资产；排名通常会在新URL被重新抓取后的几周内波动，然后恢复。将已下架的URL重定向到主页而不是相关页面是导致问题最常见的方式。
- 我可以在不要求客户重新输入银行卡信息的情况下迁移订阅吗？
- 仅当存储的支付令牌可移植时，这取决于谁持有它们以及两个支付处理器是否都支持转移。在承诺之前，务必具体地以书面形式确认这一点——这是最能决定订阅迁移是否可行的唯一事实。
- 我应该同时迁移店面和账单系统吗？
- 不。首先切换店面，证明其稳定运行数周，然后再迁移账单系统。同时进行两者意味着任何故障都有两个可能的起因，并且您的回滚操作必须同时撤销两者——而账单故障是您无法承受缓慢诊断的。