Skip to content
  • There are no suggestions because the search field is empty.

Cross-Origin Iframe: Third-Party Cookie Blocking and Tracking Issues

Fix Convert Experiences tracking issues caused by third-party cookie blocking in cross-origin iframes by passing the visitor ID via URL parameters.

Author: George F. Crew

IN THIS ARTICLE YOU WILL:

Overview

When running Convert Experiences within a cross-origin iframe, you may encounter tracking issues caused by third-party cookie blocking. This article explains the problem, its technical cause, and the recommended workaround using the visitor ID.

Problem Description

Symptoms

You may notice one or more of the following:

  • Experiences running within an iframe fail to execute or track properly.

  • Manually granting cookie consent with

_conv_q.push({ what: "consentGiven" });

does not resolve the issue.

  • Browser console logs may show repeated consent-related messages even after permission is granted.

Affected Setup

This issue occurs when:

  • The parent page and iframe are on different domains (cross-origin), and

  • The browser has third-party cookies blocked (which is the default in many modern browsers).

Example scenario:

  • Parent page: garagedoorseattle.com

  • Iframe: assets.a2o-static.com

Technical Explanation

Root Cause

When third-party cookies are blocked in a cross-origin iframe context, the following loop occurs:

  1. consentGiven() is called to re-enable tracking.

  2. consentGiven() internally calls run() to start tracking.

  3. run() performs a cookie availability test.

  4. The cookie test fails because the browser continues blocking third-party cookies in the iframe.

  5. This failed test triggers consentRequired() again.

Result: an infinite loop:

consentGiven() → run() → cookie test fails → consentRequired() → consentGiven() → ...

Why This Happens

Browsers treat cookies set in a cross-origin iframe as third-party cookies when:

  • The iframe domain differs from the parent page domain, and

  • Third-party cookie blocking is enabled (default in Safari, and increasingly common in Chrome and Firefox).

Because of this, the cookie availability check fails: the iframe cannot access or set cookies that would persist across different origins. Convert’s tracking logic interprets this as a failure and keeps falling back to requesting consent and re-testing.

Solution: Pass Visitor ID via Query Parameter

The Workaround

There is one viable workaround in the current code path: if the visitor is treated as “external”, the cookie-block test is bypassed.

You can achieve this by passing the visitor ID from the parent page into the iframe via the _conv_vid query parameter.

Implementation Steps

1. Obtain the Visitor ID on the Parent Page

In the parent page context, get the visitor ID using the Convert tracking snippet:

// In parent page context
var visitorId = convert.getCurrentVisitorData().visitorId;

2. Append the Visitor ID to the Iframe URL

Modify the iframe URL to include the visitor ID as a query parameter:

https://assets.a2o-static.com/page?_conv_vid=

Example:

<iframe 
  src="https://assets.a2o-static.com/form?_conv_vid=abc123def456" 
  width="100%" 
  height="500">
</iframe>

How It Works

When the iframe URL includes _conv_vid=<visitor_id>:

  • The iframe recognizes the visitor as “external”.

  • The cookie-block test is bypassed.

  • The iframe uses the provided visitor ID for tracking instead of relying on third-party cookie persistence within the iframe context.

As a result, experiences can execute and track properly, even when the browser blocks third-party cookies for the iframe.

Important Notes

  • The visitor ID must be valid and obtained from the same Convert project/account.

  • This workaround specifically addresses third-party cookie blocking in cross-origin iframes.

  • For server-side implementations, consider using the Convert API directly to avoid browser cookie limitations entirely.