Идентификатор посетителя в середине не одинаков для разных доменов, когда я захожу из приложения, а затем перехожу из приложения в Интернет

Question

Опыт облачного идентификатора vistor используется. Приложение, веб используют ту же библиотеку запуска Adobe. Когда я вхожу в приложение, меняются URL-адреса и меняются средние изменения, а затем, если я перехожу от приложения к веб-сайту, меняется середина страницы, и я не вижу никакого отчета о междоменном пути из приложения в Интернет?

что-нибудь мне нужно сделать с s.cookiedomainperiod или что-нибудь, чтобы сделать эту работу?

Answer 1

Идентификатор посетителя Experience Cloud не переносится автоматически из собственного мобильного приложения на (мобильную) веб-страницу. Короче говоря, нативные приложения на самом деле не хранят данные локально так же, как веб-браузеры, поэтому нет автоматической возможности использовать один и тот же механизм / источник локального хранения между ними.

Для этого необходимо добавить код в мобильное приложение, чтобы добавить mid значение целевого URL, например:

Android

String urlString = "http://www.example.com/index.php";
String urlStringWithVisitorData = Visitor.appendToURL(urlString);
Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse(urlStringWithVisitorData));
startActivity(browserIntent);

IOS

NSURL *url = [NSURL URLWithString:@”http://www.example.com/index.php"];
NSURL *urlWithVisitorData = [ADBMobile visitorAppendToURL:url];
[[UIApplication sharedApplication] openURL:urlWithVisitorData];

Если все реализовано правильно, вы должны увидеть adobe_mc= параметр добавляется к целевому URL. Затем, при просмотре страницы целевой страницы, если у вас есть реализованные библиотеки Adobe Analytics javascript и библиотеки Experience Cloud Visitor ID, они будут автоматически искать и использовать это значение вместо того, чтобы генерировать новое значение (для этого не требуется никакой настройки / кодирования)).

Обновить:

@Ramaiyavraghvendra Вы сделали комментарий:

Привет @Crayon, mny спасибо за ваш глубокий ответ. Мне жаль, что я пропустил, чтобы сообщить, что это приложение не является родным, но это приложение SPA. Таким образом, реализация всего приложения также осуществляется через запуск. Не могли бы вы помочь в этом случае?

Я не совсем уверен, что понимаю вашу проблему. Если вы НЕ переходите с нативного мобильного приложения на веб-страницу, и ваше мобильное приложение на самом деле представляет собой веб-приложение SPA, которое выводит Launch в виде обычного кода JavaScript во всем приложении, то вам не нужно ничего делать; служба Experience Cloud ID должна переносить идентификатор со страницы на страницу.

Поэтому мне кажется, что, возможно, ваши настройки Experience Cloud Visitor ID и / или сервера сбора данных Adobe Analytics настроены неправильно. Переменные периода в домене cookie могут быть проблемой, если для входа в систему необходимо перейти с сайта www.mysite.com на www.mysite.co.uk или аналогичный, но это не должно быть проблемой, если у TLD такое же количество # периодов.

Или trackingServer а также trackingServerSecure переменные могут быть неправильно настроены. На практике я обычно не ставлю trackingServerSecure совсем. Эти переменные приводят к путанице и ошибкам IMO в разных сценариях по сравнению с тем, что вы используете, поэтому я склонен использовать значение "secure" в trackingServer поле и покинуть trackingServerSecure пусто, и затем Experience Cloud Visitor ID и Adobe Analytics просто будут использовать безопасную версию 100% времени.

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

Кроме того, вы можете проверить заголовки ответа для ваших авторизованных страниц. Возможно, они настроены на отклонение определенных существующих файлов cookie, отличных от https, или чего-то еще, что фактически приводит к невозможности чтения существующих файлов cookie и заставляет службу Experience Cloud ID создавать новый идентификатор и файлы cookie.

Или... может быть, ваше приложение является нативным мобильным приложением, но использует обертку http для загрузки веб-страниц, так что это в основном веб-браузер, но фактически это похоже на переход от одного веб-браузера к другому (например, начиная с www.site.com /pageA в Chrome, а затем скопируйте / вставьте этот URL в Internet Explorer для просмотра). Так эффективно, разные баночки печенья.

Launch (или DTM) + Experience Cloud ID (методы Javascript)

В таких случаях, как последние 2 абзаца, вы должны украсить свои целевые ссылки так же, как мой первоначальный ответ, но с использованием синтаксиса JavaScript Launch + Experience Cloud ID Service:

_satellite.getVisitorId().appendVisitorIDsTo('[your url here]');

Вы пишете некоторый код, чтобы получить целевой URL ссылки. Затем выполните его через этот код, чтобы вернуть URL с добавленными к ним параметрами, а затем обновите ссылку с помощью нового URL-адреса.

Супер общий пример, который просто обновляет все ссылки на странице. На практике это следует делать только для соответствующих ссылок, на которые перенаправлен посетитель.

var urls = document.querySelectorAll('a');
for (var i = 0, l = urls.length; i < l; i++) {
    if (urls[i].href) {
        urls[i].href = _satellite.getVisitorId().appendVisitorIDsTo(urls[i].href);
    }
}