AppMeasurement (s_code) in DTM Question | Adobe Higher Education
Skip to main content
S
scottt6073095
Level 4
June 20, 2017
Beantwortet

AppMeasurement (s_code) in DTM Question

  • June 20, 2017
  • 2 Antworten
  • 1824 Ansichten

We are currently using modified s_code in DTM but I would like to revert back to "managed by Adobe" however I had a few questions regarding the custom code we have in the s_code file:

Custom Code in s_code:

  • Using the YouTube API for video tracking
  • DemandBase code from Data Connector
  • doPlugins for:
    • getPercentPageViewed
    • getNewRepeat
    • getVisitNum
    • getLoadTime
    • getTimeParting

Questions:

  1. Can I migrate the YouTube API, DemandBase API and the doPlugins to the "Customize Page Code" section?
  2. Any other workarounds to get the custom code to still work but have s_code managed by Adobe?
  3. If I can use the "Customize Page Code" section then when would I execute, "After"?

Thank you in advance for any help,

Scott

    Dieses Thema wurde für Antworten geschlossen.
    Beste Antwort von dtmWoot

    Hi Scott -

    I think migrating to Adobe Managed App Measurement is a smart idea. The configuration you've described is most likely a legacy implementation, and with few exceptions, is not necessary. This setup also has the potential to cause issues with the implementation as it scales.

    The best way to migrate is to move all "do_plugins" code to custom page code (as you've indicated) and leave the default execution settings.

    If you need to migrate 3rd party tags and are concerned about load timing, I would add each tag separately as 3rd party JS (for better control and management) and then decide, based on each tag, if you will need to configure the load of the tag (top of page, asynchronous, page bottom, etc).

    Hope this helps.

    2 Antworten

    dtmWoot
    dtmWootAntwort
    June 20, 2017

    Hi Scott -

    I think migrating to Adobe Managed App Measurement is a smart idea. The configuration you've described is most likely a legacy implementation, and with few exceptions, is not necessary. This setup also has the potential to cause issues with the implementation as it scales.

    The best way to migrate is to move all "do_plugins" code to custom page code (as you've indicated) and leave the default execution settings.

    If you need to migrate 3rd party tags and are concerned about load timing, I would add each tag separately as 3rd party JS (for better control and management) and then decide, based on each tag, if you will need to configure the load of the tag (top of page, asynchronous, page bottom, etc).

    Hope this helps.

      jantzen_b
      Adobe Employee
      jantzen_bAdobe Employee
      Adobe Employee
      June 20, 2017

      Hi Scott,

      I agree with Mark's answer. One additional thing that you might run into is scoping on the s object. If you do, we have some workarounds that will globally scope the s object. Let me know if you run into that and I'll see if I can find the latest recommendation.

      Cheers,
      Jantzen

      Allgemeine NutzungsbedingungenAccessibility statement

      Loading footer...