我们在网站上有很多交易，因此，出于这个原因，我们在确认屏幕（已设置为PurchaseID）中回收了预订确认号/订单ID号。由于我们正在重新使用预订确认号，因此为了使我们的purchaseID唯一，我们使用管道直径将时间戳添加到purchaseID变量中。因此公式如下：
purchaseID = order_id +'|' +时间戳记（当前日期）。
我在这里的担心是，假设我今天进行了预订，并且我的购买ID如下-
purchaseID = 5747118 | 2019年6月7日
现在，我明天将在2天，3天等之后再次访问我的确认屏幕，并且我看到Adobe呼叫正在触发。因为我在不同日期访问了确认页面，所以时间戳更改了，因此我的purchaseID不再唯一。即使我看到相同的预订确认页面，我的purchaseID现在也不唯一。这是否意味着，每当我在不同的日期每次查看确认屏幕时，我的预订/收入都会被计入多次？如果是，解决此问题的最佳方法是什么？
答案 0 :(得分：0)
所以听起来有人可以去您的网站进行购买并查看确认页面，然后再返回同一确认页面，而无需进行实际购买。也许他们将页面标记为书签，稍后再返回以供参考。也许是因为原因，他们刷新了页面。
您的网站是否向其信用卡收取再次访问该页面的费用？我当然希望不会。您的网站/编码的结构应避免每次客户再次浏览该页面时都向客户收取更多的费用。
并且用于输出Adobe Analytics的代码逻辑应采用相同的结构：您的编码逻辑应该是仅在实际发生购买时才输出购买事件和变量（例如purchaseID） em>。
实际上，由于网站的结构，有时有时不容易做到。 purchaseID存在的部分原因是对购买进行重复数据删除，以便如果重新弹出购买事件和数据，则将对它们进行重复数据删除。但是只有当访问者刷新页面时输出 same PurchaseID或稍后再返回页面时（他们实际上并没有进行其他购买）时，此方法才有效。
这听起来好像是您使用您推送到purchaseID的原始预订确认号码一样。但是，当您决定将当前的日期戳添加到组合中时，事情就开始进行了，因为您开始回收预订确认号码。好吧，你不能那样做。您可以使用动态值（例如当前日期/时间戳）作为值的一部分，但必须记住，并在将来输出。
也许这涉及到在数据库中添加额外的列，其中包含购买的日期/时间戳（我肯定已经确定您已经拥有），然后在您获得预订确认号时提取该值。
或者解决方案可能涉及退后一步，重新考虑您正在回收预订确认码的事实。对我来说，这似乎是个坏主意。正如您自己所看到的，对于您的Adobe Analytics实施绝对是一个坏主意。但这通常不是一个坏主意吗？如果某个客户今天购买某商品并具有＃12345作为交易参考的凭证，然后明天，一周，一年或从现在开始的任何其他日期，则其他客户获得相同的编号会怎样？
理所当然地，您最终会陷入困境，试图找出哪个客户购买了什么。就其性质而言，交易ID应该永远是交易唯一的。因此，我为您推荐的第一个解决方案是停止回收您的预订确认号码。如果需要，请移至其他格式（例如UUID）。
如果不这样做，我的下一个建议就是我在几段之前所说的内容，即在实际购买时（肯定已经拥有）将日期/时间戳存储在列中，然后抓住并使用该值并带有预订确认号＃作为定值，而不是即时生成当前日期（这绝对无效）。