Expand my Community achievements bar.

Help shape the future of AI assistance by participating in this quick card sorting activity. Your input will help create a more effective system that better serves your needs and those of your colleagues.
SOLVED

Adobe Launch and clicks from within an externally hosted iFrame

Avatar

Level 2

Despite my pleas about the evils of iFrames, we will soon be implementing an externally hosted third party iFrame on our site with requirements to track user engagement from within the iFrame into our AA report suites.

I'm not expecting too many bruises from the postMessage/addEventListener approach; but I have a few questions about about best practices for links from within the iFrame to other pages on our site.

Elsewhere on our site we fire a custom link on most clicks, and I'm certainly hoping to do something similar here.

Should the link destination be included in the postMessage and then the actual navigation be handled from the parent page by Launch after the custom link fires?  Or should the parent postMessage back to the iFrame after the custom link, so the navigation can proceed?  I'm more than a little worried on what happens with referring domain/URL and a number of other variables, if this is the case.

Thanks in advance for your time.

 

 

 

1 Accepted Solution

Avatar

Correct answer by
Level 6

Hi @francis_harris ,

 

I think your question is getting a bit confusing because a POST request may refer to the linked page, the beacon sent to Adobe, or even some other resource altogether.  In fact, you can even influence Launch's choice of whether to send a beacon with a GET vs. POST requests using the useBeacon setting and meeting other criteria for payload size. Sorry, I see you were referring to the postMessage API, to send everything to the parent.

 

For the issue of capturing referrer in an iframe click, you should manually overwrite the referrer value on the next page before the pageview beacon has fired. To do this you could forward data to the next page using many techniques. E.g.s: query string params appended to links or session storage. Then, reading from the stored location, you can override the default referrer on the next page by setting it in the AppMeasurement object, ref. Codewise, it would make sense for this to live two places, store the true referrer at the time of the actual click event (when you write the event listener), and a separate piece while the page is loading (could even be custom code during the pageview rule(s)) to see if a value was provided. If using session storage, just be safe and clear the value after reading it.

 

View solution in original post

2 Replies

Avatar

Correct answer by
Level 6

Hi @francis_harris ,

 

I think your question is getting a bit confusing because a POST request may refer to the linked page, the beacon sent to Adobe, or even some other resource altogether.  In fact, you can even influence Launch's choice of whether to send a beacon with a GET vs. POST requests using the useBeacon setting and meeting other criteria for payload size. Sorry, I see you were referring to the postMessage API, to send everything to the parent.

 

For the issue of capturing referrer in an iframe click, you should manually overwrite the referrer value on the next page before the pageview beacon has fired. To do this you could forward data to the next page using many techniques. E.g.s: query string params appended to links or session storage. Then, reading from the stored location, you can override the default referrer on the next page by setting it in the AppMeasurement object, ref. Codewise, it would make sense for this to live two places, store the true referrer at the time of the actual click event (when you write the event listener), and a separate piece while the page is loading (could even be custom code during the pageview rule(s)) to see if a value was provided. If using session storage, just be safe and clear the value after reading it.

 

Avatar

Community Advisor

I feel your pain. 

 


Should the link destination be included in the postMessage and then the actual navigation be handled from the parent page by Launch after the custom link fires?  Or should the parent postMessage back to the iFrame after the custom link, so the navigation can proceed?

I think the second option is "safer", because it should ensure that Launch has sent the Custom Link beacon before navigation happens. But that means your users could have a longer delay between clicking a link to when the navigation occurs.

Having said that, I find the implementation to be very confusing and complicated. I.e.

  1. Parent page loads IFrame.
  2. IFrame page loads.
  3. User clicks in IFrame.
  4. Parent detects the click inside the IFrame.
  5. Parent redirects to another page.
  6. Go back to step 1.

Is that really the case? If so, I can't understand the logic for that setup either.