Forward Support in Launch for DTM's _satellite.getVar("window. | Community
Skip to main content
Stewart_Schilling
Community Advisor
Community Advisor
June 13, 2018
New

Forward Support in Launch for DTM's _satellite.getVar("window.

  • June 13, 2018
  • 3 replies
  • 5330 views

In DTM,  _satellite.getVar will honor the "window." prefix in the first argument.

In Launch, this is not supported.

For example :

_satellite.getVar("window.digitalData.page.pageInfo.pageName")

It is fairly common practice in DTM to use the above as it will fail gracefully if any part of the nested object is undefined.

The same problem exists for "param.", "event.", "rand", and "target." prefixes

These may present migration hurdles for some DTM implementations.

The DTM to Launch Migration Assessment at https://www.searchdiscovery.com/solutions/partners/adobe/adobe-launch/dtm-launch-assessment/  presently flags these cases as issues that will need to be fixed when migrating.

3 replies

Level 6
June 14, 2018

I agree that this would be a good feature, especially if it was working in DTM.

But for this example case I would create data elements pointing to the datalayer anyway. With the ContextHub Extension and a custom JSON Schema this is rather comfortable to do and as far as I know there it also fails gracefully.

Stewart_Schilling
Community Advisor
Community Advisor
June 14, 2018

Agreed, there are many ways to skin a cat.  I had logged this as an issue in launch-beta a long time ago, but it didn't get any response. I logged this here as an idea since _satellite.getVar has been on the list of DTM functions that are meant to be forward compatible to Launch.  I'd expect the function to work as it did in DTM and have deprecation notices if being used in a way that is not intended for long-term support. 

Level 4
February 12, 2019

Whoa, I didn't know this was an option in DTM.  This is such a streamlined way to interact with data layers without having to utilize a new data element or making sure you are being really defensive in your coding.

Thanks for bringing this up Stewart - a great feature/idea that I wish I knew back with DTM