Acoustic Measure for Tealeaf
Cross-domain measurement makes it possible for Acoustic Experience Analytics (Tealeaf) to see sessions from two related sites as a single session. This is sometimes called site linking or cross-domain tracking.
Suppose you have an online store and a 3rd-party shopping cart hosted on another domain, such as:
1. www.example-petstore.com
2. www.example-commerce-host.com/example-petstore/
Without cross-domain measurement, a user who arrives to your online store and then proceeds to your 3rd-party shopping cart is counted as two separate users, with two separate sessions of different durations.
Cross-domain measurement enables Acoustic Experience Analytics (Tealeaf) to see this as a single session by a single user. A user to your online store who proceeds to your shopping cart is counted as one user, instead of two users, and the session they started on the store site is continued through to the time spent on the shopping cart site. The customer’s entire journey can then be replayed as one session.
About cross-domain measurement. Google. Retrieved April 10, 2020, from https://support.google.com/analytics/answer/1033876?hl=en&ref_topic=2772342
Sauer, J. (2020, March 2). How To Setup Cross-Domain Tracking In Google Analytics. Data Driven. https://www.datadrivenu.com/cross-domain-tracking/
-
Aaron Gregory
- Apr 11 2020
- Under consideration
|
How will this idea be used?
1. A user visits the SiteA.app. 2. The Tealeaf.js file loads and checks to see if a TLTSID cookie exists on the current domain (SiteA.app). No TLTSID cookie exists on the current domain. 3. Since the cookie doesn’t exists, an AJAX call is made to Acoustic Measure with your AppKey (example: 123-GoAcoustic-YourAppKey). 4. Acoustic Measure receives the request and creates a UUID (ex: ABC-GoAcoustic-UniqueID). Next, it uses the UUID and AppKey to generate a SHA-2 hash for the TLTSID value (ex: 123ABC-GoAcoustic-TLTSID). 5. Acoustic Measure responds to the request from the page with the TLTSID value. 6. The Tealeaf.js library reads the response, gets the TLTSID value, and adds a TLTSID cookie for SiteA.app to the browser. 7. As part of the response, Acoustic Measure returns the UUID as a cookie in the header. The browser automatically adds the cookie to the Acoustic Measure domain. 8. Acoustic Experience Analytics (Tealeaf) data is captured and sent to the Acoustic Collector with the TLTSID. 9. The user navigates to SiteB.app to complete their journey. 10. SiteB.app webpage loads and the Tealeaf.js checks to see if a TLTSID cookie exists on the current domain. No TLTSID cookie exists on this domain, so Tealeaf.js needs to ask Acoustic Measure for the TLTSID value. 11. A request is made to Acoustic Measure with the AppKey (123-GoAcoustic-YourAppKey) and the UUID (ABC-GoAcoustic-UniqueID). 12. Acoustic Measure receives the UUID and AppKey. Next, it uses those values to generate a SHA-2 hash. This hash value is the same as the TLTSID that was created for the SiteA.app domain. 13. Acoustic Measure responds to the request with the TLTSID value (123ABC-GoAcoustic-TLTSID). 14. The Tealeaf.js library reads the response, gets the TLTSID value, and adds the same TLTSID cookie for SiteB.app to the browser. 15. Acoustic Experience Analytics (Tealeaf) data is captured and sent to the Acoustic Collector with the TLTSID. |
|
| What is your industry? | Non-Industry Specific |
| What is the idea priority? | High |
Related ideas
Visualizing the holistic journey would be really great. Your inputs to below my question would definitely helpful to better understand the differentiator of UUID and when that could add value.
On step.2 above - isn't TLTSID expected always when there is Tealeaf.js(siteA). When that's in place, Tealeaf.JS loaded on siteB supposed to use the existing before generating one. It's working for us.
Would love this for On Prem as well
Great idea, really helpful!
Yes we liked this idea to be implement in Tealeaf Product and we need to use this feature in our account soon.