The Technical Mechanics of Click Tracking, Landing Page Macros, and AdAttributionKit View-Through Attribution

When a user taps a rendered programmatic creative, the browser or in-app webview rarely navigates directly to the advertiser's destination URL; instead, it initiates a sequential cascade of HTTP 302 temporary redirects across two to four independent ad servers. Each hop in this redirect chain must record the click event in its respective ledger, decode the downstream destination parameter, and forward the client to the next URI in under 150 milliseconds before the user abandons the navigation. A single misconfigured macro or unescaped ampersand in that chain severs the handoff between the publisher's ad server, the SSP, and the buying DSP.

From a yield architecture standpoint, broken or truncated click chains cause immediate revenue degradation that extends well beyond cost-per-click (CPC) campaigns. When Google Ad Manager (GAM) records a user click that never resolves at the DSP or advertiser landing page, the resulting click-to-landing-page discrepancy triggers automated buy-side quality filters. Tier-1 DSPs continuously monitor the ratio of recorded clicks to verified post-click page loads (or app store sheet presentations) across every SupplyChain (schain) node. When a placement exhibits a discrepancy exceeding 15% to 20%, bid shading algorithms penalize the inventory's expected conversion value, or QPS throttling rules exclude the placement ID from performance-oriented deals entirely.

Modern attribution frameworks compound this requirement by pairing click redirect fidelity with sub-second impression timestamping and cryptographic operating-system verification. Operating a high-yield, 100% Google-friendly, HUMAN and Pixalate IVT-clean supply footprint across web, mobile app, and Connected TV (CTV) requires deterministic alignment across three connected subsystems: ad server click macro chaining, OpenRTB 2.6 fulfilled impression timestamp substitution, and Apple AdAttributionKit click-through and view-through signature verification.

How Click Macros (%%CLICK_URL_UNESC%% and %%CLICK_URL_ESC%%) Chain Across Ad Servers

Programmatic click tracking operates as a nested, onion-layered URI structure where the outermost URL belongs to the system closest to the user interaction, and the innermost URL is the final advertiser landing page. When a user clicks an ad rendered inside an iframe or mobile webview, the request must hit the publisher's ad server first, redirect to the SSP or mediation wrapper's click tracker, redirect again to the DSP's click server, and finally resolve at the advertiser's measurement partner or landing page. To construct this chain dynamically at ad-serving time, Google Publisher Tag and Google Ad Manager use the %%CLICK_URL_UNESC%% and %%CLICK_URL_ESC%% clickthrough macros to prepend Ad Manager click tracking URLs to third-party creative landing pages.

The mechanical difference between %%CLICK_URL_UNESC%% and %%CLICK_URL_ESC%% lies in how RFC 3986 percent-encoding is applied to reserved URI delimiter characters such as :, /, ?, &, and =. When GAM expands %%CLICK_URL_UNESC%%, it injects a raw, unescaped redirect prefix, typically formatted as https://adclick.g.doubleclick.net/pcs/click?xai=...&sig=...&adurl=. Because this string contains raw colons, slashes, and query delimiters, it can only sit at the very front of a URL string (where the browser navigates to GAM first) or inside a JavaScript variable where the script itself will execute encodeURIComponent() at runtime before passing the value downstream.

Conversely, when a third-party creative server or DSP tag acts as the primary anchor href and expects GAM's click tracker to be passed inside a query parameter (such as ?click= or &redirect=), injecting an unescaped URL will corrupt the outer query string. In this topology, AdOps engineers must use %%CLICK_URL_ESC%%, which outputs a single-percent-encoded string (https%3A%2F%2Fadclick.g.doubleclick.net%2Fpcs%2Fclick%3Fxai%3D...%26adurl%3D). When the user clicks the ad, the request hits the third-party server first; that server logs the click, reads its redirect query parameter, performs a single URL-decode pass to restore the raw https://adclick.g.doubleclick.net/... syntax, appends the final landing page to the trailing &adurl= parameter, and issues an HTTP 302 redirect to GAM.

<!-- Scenario A: GAM sits first in the redirect chain (Unescaped) -->
<a href="%%CLICK_URL_UNESC%%https%3A%2F%2Fssp-tracker.skyboosts.com%2Fclick%3Fbid_id%3D99481%26redir%3Dhttps%253A%252F%252Fadvertiser.example.com%252Flanding" target="_blank">
  <img src="https://cdn.skyboosts.com/creatives/banner_300x250.png" width="300" height="250" alt="Ad" />
</a>

<!-- Scenario B: Third-party DSP server sits first; GAM tracker passed as query parameter (Escaped once) -->
<script>
  const dspClickBase = "https://dsp-click.example.net/clk?imp=7721&gam_click=%%CLICK_URL_ESC%%&lp=";
  const finalLandingPage = encodeURIComponent("https://advertiser.example.com/offer?utm_source=programmatic&utm_medium=cpm");
  document.getElementById("ad-anchor").href = dspClickBase + finalLandingPage;
</script>

Notice in Scenario A above that as additional servers join the redirect chain, each nested hop requires an incremental level of percent-encoding (%3A at hop two, %253A at hop three). Every HTTP 302 server in the relay strips away exactly one layer of percent-encoding when parsing its query string and writing the Location response header for the next hop. Maintaining strict parity across these encoding layers ensures that our click and conversion reporting aligns within a sub-1% tolerance against both GAM creative-level logs and buy-side DSP attribution dashboards.

Diagnosing Broken Clicks Caused by Double-Escaping or Missing HTTPS Upgrades

Two failure modes account for the vast majority of broken programmatic clicks in production: double-escaping (https%253A%252F%252F) and premature query string truncation caused by under-escaping. Double-escaping occurs when an AdOps engineer configures %%CLICK_URL_ESC%% inside a third-party JavaScript tag or Prebid creative wrapper that automatically runs encodeURIComponent() on the macro value at runtime. Because %%CLICK_URL_ESC%% is already percent-encoded by GAM (%3A%2F%2F), the JavaScript encodeURIComponent() call encodes the percent sign (%) itself into %25, transforming the protocol prefix into https%253A%252F%252F.

When the upstream ad server receives this double-encoded parameter and executes its standard single URL-decode pass, it emits an HTTP 302 response with Location: https%3A%2F%2Fadclick.g.doubleclick.net.... Because the scheme separator :// remains encoded as %3A%2F%2F, Chromium and WebKit parsers do not recognize the string as an absolute URI with an https scheme. Instead, the browser interprets the string as a relative path appended to the upstream ad server's current directory, resulting in an immediate HTTP 400 Bad Request or 404 Not Found error and a dead end for the user.

Under-escaping produces the opposite failure. If %%CLICK_URL_UNESC%% is placed directly inside a third-party tracker's query parameter without encoding, the raw ampersands (&) inside GAM's tracking URL (&sig=...&adurl=) are parsed by the third-party server as top-level parameters belonging to its own endpoint rather than part of the nested redirect URL. Consequently, the adurl= suffix is severed from the redirect target. When the third-party server redirects the browser to GAM, the trailing destination URL is missing, and GAM halts the navigation on a blank HTTP 200 or 204 page.

/**
 * Pre-flight AdOps Click Chain Validator
 * Detects double-escaped protocols, unescaped nested query delimiters, and HTTP downgrades.
 */
function validateClickChain(resolvedClickUrl) {
  const diagnostics = { valid: true, errors: [], hops: [] };

  // 1. Check for double-encoded protocol schemes (%253A%252F%252F) at top level or first hop
  if (/https?%253A%252F%252F/i.test(resolvedClickUrl)) {
    diagnostics.valid = false;
    diagnostics.errors.push("CRITICAL: Double-escaped URI scheme detected (%253A%252F%252F). Replace %%CLICK_URL_ESC%% with %%CLICK_URL_UNESC%% if script calls encodeURIComponent().");
  }

  // 2. Walk nested redirect hops to verify HTTPS enforcement and query truncation
  let currentUrl = resolvedClickUrl;
  let depth = 0;
  const redirectParamRegex = /[?&](?:adurl|redir|redirect|click|url|u|lp)=([^&]+)/i;

  while (currentUrl && depth < 5) {
    diagnostics.hops.push({ depth, url: currentUrl });

    if (currentUrl.startsWith("http://")) {
      diagnostics.valid = false;
      diagnostics.errors.push(`SECURITY: Insecure HTTP hop at depth ${depth} (${currentUrl}). Blocked by iOS ATS and Chromium mixed-content rules.`);
    }

    // Check if an unescaped https:// appears mid-query without percent-encoding
    const rawQueryIndex = currentUrl.indexOf("?");
    if (rawQueryIndex !== -1) {
      const queryPart = currentUrl.substring(rawQueryIndex + 1);
      if (/=https?:\/\/[^&]+&/i.test(queryPart) && !queryPart.endsWith("adurl=")) {
        diagnostics.valid = false;
        diagnostics.errors.push(`TRUNCATION: Unescaped nested URL with raw '&' delimiters detected at depth ${depth}. Downstream parameters will be stripped.`);
      }
    }

    const match = currentUrl.match(redirectParamRegex);
    if (match && match[1]) {
      currentUrl = decodeURIComponent(match[1]);
      depth++;
    } else if (currentUrl.includes("&adurl=http")) {
      currentUrl = currentUrl.split("&adurl=")[1];
      depth++;
    } else {
      break;
    }
  }

  return diagnostics;
}

Protocol downgrades represent a third silent killer of click-through rates, particularly in mobile app environments. Both iOS App Transport Security (ATS) inside WKWebView and modern Chromium security policies reject redirect chains that downgrade from https:// to http:// mid-flight. While GAM and tier-1 SSPs default to TLS-encrypted endpoints, legacy third-party tracking wrappers or unvalidated advertiser landing pages occasionally hardcode http:// prefixes. Inside our unified monetization platform, automated creative scanning pipelines run static and dynamic redirect inspection prior to serving, rejecting any creative payload that lacks end-to-end HTTPS transport or exhibits malformed macro nesting.

How OpenRTB ${AUCTION_IMP_TS} Macros Signal Exact Fulfilled Impression Timestamps

Click tracking cannot be engineered in isolation from impression timing. Every modern attribution model, anti-fraud filter, and billing reconciliation engine evaluates the time-to-click delta (t_click - t_impression). If a user clicks an ad 400 milliseconds after the impression beacon fires, or 45 minutes after an auction clears, the validity of that event depends entirely on whether the recorded impression timestamp reflects when the creative actually rendered on the user's screen or merely when the server-side auction concluded.

In synchronous web display auctions, the latency delta between the SSP's auction close and the browser's creative render is typically 80 to 300 milliseconds. However, in mobile app interstitials, rewarded video pre-fetching, and CTV Server-Side Ad Insertion (SSAI), an SSP and DSP may execute the OpenRTB auction two to five minutes before the user reaches the natural ad break or triggers the interstitial show method. If a DSP records the impression timestamp at the moment the auction clears (or when a server-side win notice fires) rather than when the video frame or interstitial actually displays, two severe operational problems emerge:

1. A legitimate click that occurs 10 seconds after the interstitial appears on screen looks to the DSP's attribution engine as if it occurred four minutes after the impression, skewing engagement decay curves.
2. Conversely, if a billing notice (burl) fires late without signaling the exact fulfillment timestamp, clock skew between the client SDK and DSP ingestion cluster can cause impressions to be flagged as expired or out-of-window.

To eliminate this discrepancy across asynchronous and pre-cached formats, the IAB Tech Lab OpenRTB 2.6 specification (v2.6-202303 and later) introduced the ${AUCTION_IMP_TS} substitution macro to signal the exact timestamp when an impression was fulfilled and displayed on screen, a capability vital for delayed CTV and mobile billing beacons.

{
  "id": "80ce30c53c16e",
  "bidid": "skyboosts-ibr-9920184",
  "cur": "USD",
  "seatbid": [
    {
      "seat": "dsp-tier1-seat-42",
      "bid": [
        {
          "id": "1",
          "impid": "101",
          "price": 14.50,
          "adid": "cr-88412",
          "cid": "camp-7710",
          "crid": "creative-video-30s",
          "burl": "https://dsp-beacon.example.net/win?bid=80ce30c53c16e&p=${AUCTION_PRICE}&ts=${AUCTION_IMP_TS}",
          "adm": "<VAST version=\"4.3\"><Ad id=\"cr-88412\"><InLine><AdSystem>Sky BoostsSSP</AdSystem><AdTitle>BrandSafeCTV</AdTitle><Impression><![CDATA[https://ssp-events.skyboosts.com/imp?id=80ce30c53c16e&p=${AUCTION_PRICE}&imp_ts=${AUCTION_IMP_TS}]]></Impression><Creatives>...</Creatives></InLine></Ad></VAST>",
          "exp": 3600
        }
      ]
    }
  ]
}

When processing the OpenRTB 2.6 bid response shown above, the resolution lifecycle splits into two distinct phases. First, immediately upon closing the auction, the SSP resolves ${AUCTION_PRICE} with the clearing CPM (for example, 14.50). Second, the ${AUCTION_IMP_TS} macro is preserved unexpanded until the client-side SDK or SSAI stitcher confirms physical render fulfillment (for instance, upon firing the OMID impressionOccurred event or parsing the firstHLS/DASH ad segment beacon). At that exact moment, the platform substitutes ${AUCTION_IMP_TS} with the Unix epoch timestamp of the screen render before dispatching the HTTP GET request to the burl and VAST <Impression> endpoints.

Configuring View-Through vs. Click-Through Attribution Windows in In-App Environments

Exact impression timestamps and deterministic click chains converge directly inside mobile in-app performance measurement, particularly under Apple's AdAttributionKit (introduced in iOS 17.4 and expanded in iOS 18 as the architectural successor to SKAdNetwork) and Google Play's Privacy Sandbox Attribution Reporting API. Unlike legacy IDFA-based deterministic matching, AdAttributionKit relies on cryptographically signed JSON Web Signatures (JWS) generated by registered ad networks at the time of impression and interaction, evaluated locally by the operating system against strict attribution windows.

AdAttributionKit distinguishes between two primary engagement paths:

• Click-Through Attribution (CTA): Triggered when a user actively taps an ad creative, passing through a validated UIEventAttributionView gesture recognizer that launches either an in-app StoreKit-rendered product sheet, a custom product page, or a universal link re-engagement flow into an already installed app.
• View-Through Attribution (VTA): Triggered when an ad creative is rendered on screen and meets minimum visibility duration requirements (without a user click), followed by the user independently installing or opening the advertised application within a short lookback window.

To support both attribution modalities without discrepancy, mobile ad SDKs must coordinate three lifecycle boundaries: cryptographic JWS generation on the ad network's key server, on-screen viewability tracking (beginView() and endView()), and click-through navigation handling.

{
  "header": {
    "alg": "ES256",
    "kid": "skyboosts-aak-key-2025-q1",
    "typ": "JWS"
  },
  "payload": {
    "version": "1.0",
    "ad-network-identifier": "skyboosts.adattribution.id",
    "source-identifier": 4829,
    "advertised-item-identifier": 1234567890,
    "publisher-item-identifier": 987654321,
    "timestamp": 1742918402000,
    "nonce": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "attribution-config": {
      "click-through-window-sec": 2592000,
      "view-through-window-sec": 86400,
      "minimum-view-time-ms": 2000
    }
  }
}

When configuring view-through versus click-through attribution windows in in-app environments, engineering teams must account for how operating-system collision rules adjudicate competing claims:

1. Priority Hierarchy (Click-Through Always Supersedes View-Through): If User A views a rewarded video ad from Network X at 10:00 AM (registering a valid view-through impression) and subsequently clicks a banner ad from Network Y at 2:00 PM before installing the advertised app at 2:05 PM, AdAttributionKit awards the winning conversion postback to Network Y's click-through engagement, regardless of how recently the view-through impression occurred.
2. Lookback Window Calibration (24-Hour VTA vs. 7-to-30-Day CTA): Because view-through impressions occur at a volume 20x to 100x higher than clicks, industry-standard DSP and MMP configurations constrain view-through lookback windows to 24 hours (86,400 seconds), while click-through lookback windows extend from 7 to 30 days. Setting overly aggressive view-through windows causes attribution cannibalization and inflates postback noise.
3. Timestamp Expiration and Pre-Cache Drift: Both SKAdNetwork 4.0 and AdAttributionKit validate the timestamp claim embedded inside the cryptographic JWS payload against the device's system clock when beginView() or the click handler is invoked. If an SSP generates and signs the JWS payload at auction time for a pre-cached interstitial that does not render for 45 minutes, the signature's timestamp will fall outside the OS validation window, causing iOS to silently drop the attribution registration. Synchronizing JWS signature generation (or token refresh) with the same client-side render hook that populates ${AUCTION_IMP_TS} guarantees that the cryptographic timestamp matches actual screen exposure.

For publisher AdOps teams and mobile SDK engineers, eliminating revenue leakage across click and attribution pipelines comes down to three concrete operational controls:

• Audit every third-party creative tag and Prebid passback in GAM using automated URL decoders to ensure %%CLICK_URL_UNESC%% is used exclusively at the head of redirect chains or inside runtime-encoded script variables, and %%CLICK_URL_ESC%% is used exclusively inside nested query parameters.
• Enforce end-to-end HTTPS across every intermediate tracking hop and require OpenRTB 2.6 ${AUCTION_IMP_TS} macro resolution on all pre-fetched mobile and SSAI CTV inventory so DSPs receive true render-time telemetry.
• Bind AdAttributionKit beginView() and JWS timestamp signing strictly to verified on-screen render events rather than auction win callbacks.

By enforcing these engineering standards across our GAM MCM, Prebid, and OpenRTB 2.6 stack, Sky Boosts protects publisher eCPMs from discrepancy-driven bid shading and delivers clean, verifiable ledger reconciliation backed by reliable Net-30 and Net-60 payouts.