What is the best way to send strings (vectors) of data using a single sever call on exit link | Community
Skip to main content
G
glenr47392026
Level 2
May 28, 2019
Solved

What is the best way to send strings (vectors) of data using a single sever call on exit link

  • May 28, 2019
  • 5 replies
  • 2581 views

We want to enhance our engagement reporting by collect data on interaction with Key elements for a content site.

I want to collect information on Important page sections by collecting how long each one is in the view port, and if was it moused- over.

Initially the list might be limited to collecting 3 or 4 per page, but would like to expand that to all important elements (20?) with dwell time.

I don't want to waste a server call on each of these- rather gather them as strings or value pairs pushed to the dataLayer.

Upon exit - push all the engagement data using one (exit link) server call

so:

ITEM          DURATION        Mouse- Over

Key item 1    20 seconds        true

Key item 2   <5 seconds         false

Key item 6    20 seconds        true

Key item 8   <90 seconds       true

Key item 9  20 seconds          false

+ other dataLayer values

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
    Best answer by Andrey_Osadchuk

    Hi glenr47392026,

    The exit link may not be the best dimension to collect the data about the onpage interactions. If you send this data from the page, consider switching to custom links.

    To save server calls, you may want to store the engagement data in local storage and append it to the page view server call on next page. In addition to that, fire an s.tl() call before the unload event if the visitor navigates to another domain (check the link destination URL, href value), and reset the local storage .

    P.S.: the exit links are used to track clicks on the links referring to third-party resources (the sites that are not tracked in the report suite the page views are collected to).

    5 replies

    Andrey_Osadchuk
    Andrey_OsadchukAccepted solution
    Level 10
    June 17, 2019

    Hi glenr47392026,

    The exit link may not be the best dimension to collect the data about the onpage interactions. If you send this data from the page, consider switching to custom links.

    To save server calls, you may want to store the engagement data in local storage and append it to the page view server call on next page. In addition to that, fire an s.tl() call before the unload event if the visitor navigates to another domain (check the link destination URL, href value), and reset the local storage .

    P.S.: the exit links are used to track clicks on the links referring to third-party resources (the sites that are not tracked in the report suite the page views are collected to).

    L
    ltaparia
    Level 2
    June 18, 2019

    Hi Andrey, can you please let me know on how to fire an s.tl() call before the unload event if the visitor navigates to another domain (check the link destination URL, href value)? Have you tried this? As per challenges faced by me and leaned that it can't be done. The new location is private/sensitive information. Nobody wants you to know which sites they visit when they leave your site.

    G
    glenr47392026Author
    Level 2
    June 18, 2019

    Hi  Andrey:

    Thank you for responding.

    You are a breathe of fresh air in the smoke screen that is Adobe documentation (or lack thereof).

    This is exactly the same conclusion I came to a few days after posting, despite those around me.

    Everyone (including my Adobe rep) thought I was crazy- but no one could explain why it wouldn't work.

    Thank you so much for the validation.

    I still have to work out the details of how to send the info from the previous page events to the correct page without incrementing the PV.

    Also I didn't know there was a way of capturing the exit page info using the unload event.

    Have you used this method effectively in production? Can you address Itaparia's concerns?

    One detail - in case anyone references this solution- is to validate local storage is available.

    Do you think this is required, or is the amount (of local storage failures)  incidental?

    Below  is some code I found to validate that local storage is available try/catch

    God only knows what Apple and others will do next.

    And yes I notice you reset when done, like a responsible developer

    I am concerned a poor developer down road tries to troubleshoot this- and can't recreate the issue

    var hasStorage = (function() {

    try {

    localStorage.setItem(mod, mod);

    localStorage.removeItem(mod);

    return true;

    } catch (exception) {

    return false;

    }

    }());

    Thanks Again Andrey!

    I wish I could afford your Launch Course as you clearly know what you are doing.

    Glen

    Andrey_Osadchuk
    Andrey_Osadchuk
    Level 10
    June 18, 2019

    Glen, ltaparia,

    Sorry, I can't share code snippets here, but you may want to read the following articles to begin with a solution development:

      G
      glenr47392026Author
      Level 2
      June 18, 2019

      Thanks Again Andrey!

        Terms & ConditionsAccessibility statement

        Loading footer...