Похоже, что кто-то может зайти на ваш сайт, совершить покупку и увидеть страницу подтверждения, а затем позже вернуться на ту же страницу подтверждения, не совершая еще одну покупку. Возможно, они добавили страницу в закладки и вернулись к ней позже для справки. Или, может быть, они обновили страницу, потому что причины.
Взимает ли ваш сайт свою кредитную карту за повторный доступ к странице? Я надеюсь, что нет. Ваш сайт / код должен быть структурирован таким образом, чтобы клиент не брал больше денег каждый раз, когда он снова просматривает страницу.
И ваша логика кода для вывода Adobe Analytics должна быть структурирована таким же образом: ваша логика кодирования должна заключаться в том, что вы выводите только событие покупки и переменные (например, purchaseID) , когда покупка действительно происходит .
На практике это иногда нелегко сделать из-за структуры сайта. Таким образом, часть того, почему существует purchaseID, состоит в том, чтобы дедуплицировать покупки, так что, если событие покупки и данные повторно отображаются, они будут де-дублированы. Но это работает только в том случае, если вы выводите тот же purchaseID, когда посетитель обновляет страницу или иным образом возвращается к ней позже (когда они фактически не совершают другую покупку).
Похоже, вы делали с исходным номером подтверждения бронирования, которое вы нажали на purchaseID. Но дела пошли на юг, когда вы решили добавить текущую дату в список, потому что вы начали перерабатывать номера подтверждения бронирования. Ну, ты не можешь этого сделать. Вы можете использовать динамическое значение, такое как текущая дата / отметка времени, как часть значения, но вы должны запомнить его и вывести в будущем.
Может быть, это включает в себя добавление в вашу базу данных дополнительного столбца с датой / временной отметкой покупки (которую я должен предположить, что вы наверняка уже имеете), а затем извлекаете это значение, когда вы получаете номер подтверждения бронирования.
Или, возможно, решение состоит в том, чтобы вернуться назад и переосмыслить тот факт, что вы перерабатываете номера подтверждения бронирования. Это кажется плохой идеей для меня. Это определенно плохая идея для вашей реализации Adobe Analytics, как вы сами убедились. Но разве это не плохая идея в целом? Что произойдет, если клиент сегодня что-то купит и у него будет # 12345 в качестве доказательства транзакции для ссылки, а затем завтра, через неделю, через год или что-то еще, другой клиент получит такой же номер?
Само собой разумеется, что у вас в руках будет беспорядок, пытаясь разобраться, какой клиент что купил. Идентификаторы транзакций по своей природе должны быть уникальными для транзакции. Поэтому мое самое первое рекомендуемое решение для вас - перестать перерабатывать номера подтверждения бронирования. При необходимости перейдите в другой формат (например, UUID).
Если это не удастся, моей следующей рекомендацией будет то, что я сказал несколькими парами выше, о сохранении даты / метки времени в столбце в фактическое время покупки (которое, безусловно, у вас уже есть), а затем захватите и используйте это значение вместе с с подтверждением бронирования # для использования в качестве значения с разделителями вместо создания текущей даты на лету (что абсолютно не работает).