DTM предоставляет другой набор отчетов для пользовательских ссылок и вызовов страниц?

Это мой выстрел в темноту, основанный на том, что вы сказали, и он основан на предположении, что ваши утверждения верны (например, вы не видите розовых слонов, что запрос действительно показывал ваш prod rsid в нужной части URL-адрес запроса, что вы действительно проверили свой prod rsid после того, как прошло приемлемое количество времени, без сегментов или других махинаций с фильтрами и т. д.: короче говоря, что вы знаете, как точно исполнить основную песню и танец QA ).

В соответствии с этим предположением ниже приведен сценарий, который может правдоподобно воспроизвести то, что вы описываете. Я мог бы быть частично прав или полностью неправ в вашей конкретной ситуации, но у меня нет возможности узнать наверняка, не имея доступа к вашему экземпляру DTM.

Сценарий

Короче говоря, похоже, что у вас есть смесь пользовательского кода и автоматических настроек DTM, а DTM переопределяет и / или не заботится о вашем пользовательском коде для отслеживания ссылок.

В частности, мне кажется, что у вас есть AA, реализованный как инструмент в DTM, и в настройках конфигурации у вас есть ваши rsids для производства и подготовки, указанные в текстовых полях.

Затем в разделе Общие вы либо НЕ указываете значения для Tracking Server и Tracking Server Secure, либо они установлены неверными. ценности.

Затем в разделе Управление библиотекой вы либо выбрали «Управляется Adobe», и в этом случае DTM позаботится о библиотеке, либо вы выбрали «Пользовательский» и добавляете библиотеку самостоятельно И вы НЕ установили флажок "Установить наборы отчетов с помощью пользовательского кода ниже".

Затем где-то в DTM (например, в поле Управление библиотекой > Пользовательский код или кодовое поле Настроить код страницы) у вас есть код, который выводит содержимое rsid (например, s.account, s_account, dynamicAccountList). ), а также, возможно, trackingServer и trackingServerSecure.

Наконец, вы (как и большинство других людей, потому что включение двойного сценария DTM для подготовки по сравнению с прод.. глупо) просто используете включение сценария прод на своей странице и либо используете режим отладки/постановки, либо полагаетесь на любую логику маршрутизации rsid, которую вы настроил маршрут к dev.

Итак... когда страница загружается впервые, DTM загружает библиотеку AA и устанавливает переменные и прочее на основе того, что вы указали в конфигурации инструмента. В течение этого времени он также извлекает любые пользовательские блоки кода, которые у вас есть в конфигурации инструмента, которые могут или не могут переопределять то, что вы указали в полях конфигурации инструмента, в зависимости от того, что вы включили. Затем, после этого, он выдает то, что у вас есть в правилах загрузки страницы (если есть) и т. д.

Но затем происходит щелчок по ссылке. Как я уже упоминал в других сообщениях на SO, DTM имеет это предостережение (ошибка IMO) о том, как он ссылается на объект AA после начальной загрузки страницы/запроса AA: в основном, это не так. Вместо этого он использует внутренние методы (главным из которых является метод .getS()) для создания нового экземпляра объекта AA на основе того, что вы настроили в разделе конфигурации инструмента. Что ж, вот в чем загвоздка... он НЕ учитывает и выполняет какой-либо пользовательский код, который вы сделали в полях кода в разделе конфигурации инструмента.

Так что в основном это происходит всякий раз, когда срабатывает правило, основанное на событии или прямом вызове, и оно эффективно вас портит. Почему DTM делает это? Я не знаю. IMO Adobe необходимо изменить эту функцию предупреждение об ошибке. Либо они должны провести рефакторинг DTM для выполнения блоков кода, ИЛИ они могли бы, знаете ли... просто сослаться на исходный созданный объект AA, как это сделал бы любой обычный скрипт..

Но в любом случае..

Так, например, моя теория заключается в том, что страница загружается нормально, указывает на dev rsid в зависимости от вашей настройки. Но затем вы щелкаете ссылку, и срабатывает событие, и DTM создает новый объект AA, не заботясь о вашем пользовательском коде, поэтому все, что ему нужно, это то, что у вас есть в полях конфигурации инструмента.

Поскольку DTM на самом деле не имеет никаких правил относительно rsid продукта и разработчика, которые вы указываете в этих полях (вы должны написать собственный код в полях пользовательского кода — DTM игнорирует!), он просто выталкивает rsid продукта, потому что это script включить у вас на странице.

Затем, поскольку данные фактически не отображаются в вашем prod rsid: опять же, поскольку DTM игнорирует то, что вы устанавливаете в своих настраиваемых полях кода, по умолчанию используется то, что указано в полях trackingServer в конфигурации инструмента, и мое предположение здесь они либо пустые, либо неправильные (вы должны посмотреть URL-адрес запроса на Adobe, чтобы убедиться в этом). Эта теория связана с тем, что вы сказали, что prod rsid верен, и вы видите, что выполняется запрос. Таким образом, следующим виновником будет неправильно указанный сервер отслеживания.

Итак, это моя теория того, что происходит. Может быть, все в порядке, может быть, в чем-то и правильно, надеюсь, хотя бы укажет вам правильное направление.

Изменить:

Если вы можете подтвердить, что у вас действительно все настроено именно так, то вы, естественно, спросите: «Хорошо, а что мне с этим делать?». Как я уже говорил во многих других моих ответах SO ... в основном, ваш единственный вариант - снять флажки со всех настроек, которые заставляют DTM автоматизировать AA, и во всех ваших правилах оставить раздел AA отключенным и любые переменные AA, которые вы хотите установить, установите их самостоятельно и заставьте s.t() или s.tl() вызывать себя в поле кода стороннего сценария, чтобы он продолжал ссылаться и всплывать на основе первоначально созданного экземпляра объекта AA.

Обновить

Основываясь на ваших комментариях ниже, хорошо, так что да ... это звучит так, как я описал, и объясняет появление prod rsid. Что касается данных, которые не отображаются в отчете... поэтому, если вы уверены, что сервер отслеживания настроен правильно (URL-адрес запроса выглядит хорошо), то это не проблема DTM. Вот несколько других объяснений того, почему данные не отображаются:

• Вы уверены, что запрос отправляется на ваш rsid prod? Я не знаю, что вы ищете, чтобы проверить это, но это то, где вы должны искать: в URL-адресе запроса к АА: "http://[trackingServer value]/b/ss/[s.account value]/1..."
• Запрос клика не поступает в Omniture. Убедитесь в анализаторе пакетов, что запрос действительно сделан и что вы получаете 200 OK или ответ NS_Binding_Aborted.
• Вы не ждете достаточно долго, чтобы проверить данные. Даже базовые данные об обращениях и просмотр отчетов «в реальном времени» требуют немного времени для отображения.
• У вас есть активный сегмент/фильтр, который не соответствует данным, которые вы пытаетесь просмотреть. Убедитесь, что у вас ничего не применено. Или, если вы используете эти вещи для поиска своих данных (и не видите их), убедитесь, что вы применяете их правильно.
• Вы недавно создали rsid, а дата запуска еще не прошла. Данные не будут отображаться в наборе отчетов до истечения 24 часов после указанной даты запуска.
• У вас есть правило Vista, которое влияет на отображение данных. В некоторых компаниях существует правило Vista по ряду причин, и существует миллион способов, которыми оно может повлиять на данные (например, маршрутизация в другой набор отчетов). Для дерьма и ухмылки проверьте своего разработчика (или других rsids), чтобы увидеть, появились ли там ваши данные. Даже если это не имеет смысла, по крайней мере, это шаг вперед.
• У вас есть правило исключения ботов/IP-адресов, которое собирает данные из вашего местоположения.
• Данные, отправленные по ссылке, не относятся к отчету. Например, может быть, вы смотрите, например. отчет prop10, а prop10 на самом деле не отправляется в запросе клика.

Я знаю, что многие из этих основных вещей нужно проверить, и, без сомнения, вы проверили, но проверьте еще раз. Попросите кого-нибудь проверить для вас, чтобы быть уверенным. Я не ставлю под сомнение ваши способности, но даже лучшие кодеры иногда забывают ставить крестики и расставлять точки над i и умудряются упускать очевидные вещи. Если вы уверены во всем этом, обратитесь в Adobe ClientCare, потому что я действительно не могу придумать ничего другого, что не было бы связано с проблемой с серверной частью Adobe.

Я столкнулся с аналогичной проблемой с моей реализацией. По сути, я установил переменную s.account непосредственно внутри doPlugins, чтобы она устанавливалась для всех отслеживающих вызовов. Я также написал подробности здесь: Учетная запись отслеживания DTM< /а>