Preserve the destination through nested ad-click macros

Write the intended values before encoding them

Google Ad Manager’s Macros for custom creatives documentation, checked 7 November 2026, distinguishes click macro escaping levels according to placement. Incorrect nesting can lose destination parameters. The exercise below is an original string-ownership model, not a production tag or a universal macro prescription.

Start with three independently stated facts: the outer tracking address, the destination address and the parameters belonging to each. Use reserved example domains and invented values only. Ask the technical owner to identify the actual expansion and decoding boundaries in the intended implementation. Do not count visible percent signs and guess the required macro; the same printed string can occupy a different layer in another integration.

Build a decoded ownership ledger

Use this fictional destination: https://shop.example/item?color=blue&size=wide. Its receiving page owns color and size. The outer fixture is https://tracker.example/click?slot=hero&dest=VALUE. That receiver owns slot and dest. Before any encoding, write the expected outer result as exactly two parameters, with dest containing the complete destination string. This establishes a result against which a parser output can be compared.

For a conventional query-value representation in this invented fixture, VALUE is https%3A%2F%2Fshop.example%2Fitem%3Fcolor%3Dblue%26size%3Dwide. After the outer receiver extracts and decodes that value once, the destination should again contain its two own parameters. The ledger has four columns: layer, literal input, parsed fields and intended owner. Preserve both the encoded input and decoded value; a screenshot of the final page cannot establish where a parameter went missing.

Challenge the layer boundary rather than the destination

Compare an intentionally raw substitution. Appending the unencoded destination after dest= leaves its ampersand exposed to the outer query parser in this fixture. The resulting outer fields include size, although size belongs to the shop. Now compare an extra encoding pass: the extracted value can remain an encoded string where the next component expects an address. These are different mismatches and should not be repaired with the same blind replacement.

Have the specialist demonstrate the actual parser outputs using synthetic strings in an approved isolated test. Compare each row with the ownership ledger, stopping at the first disagreement. If an intermediary legitimately adds another representation layer, add a row and document its contract rather than repeatedly decoding until the text looks familiar. Do not decode arbitrary untrusted links or visit real tracking endpoints while constructing the fixture.

Specify the correction without inventing a platform recipe

Once the failing boundary is known, ask the owner to choose the supported macro or construction method for that exact location. Record the platform, template and expansion point beside the corrected specimen. The original model proves an ownership expectation, not that every tracker performs one decoding pass or uses these parameter names. Never promote the invented URL into a live creative.

Finish by checking that the reconstructed destination retains the intended item and variant values, then hand the evidence to the normal destination-acceptance process. A correct parsing result does not establish consent, permitted tracking or a valid offer. Keep those decisions separate. Preserve the raw and parsed rows with the approved template version so a later additional wrapper cannot silently inherit an obsolete escaping assumption.

Make the reasoning concrete.

A fictional catalog team places an item address inside a tracking value. The item loads, but its size choice disappears. The first parser output shows size beside slot rather than inside dest.

The team requests a corrected isolated specimen and a documented expansion point. It does not edit or fire a real advertising tag.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Values

   What are the complete outer and inner values before representation changes?

2. Ownership

   Which receiver owns each parameter?

3. Boundary

   What exact parsing and decoding step occurs at each layer?

4. Mismatch

   Where does observed field ownership first differ from the intended ledger?

5. Scope

   Which template and platform support the proposed correction?

Watch for the wrong conclusion.

• Treating every ampersand as belonging to the same receiver.
• Adding decoding passes until a URL looks readable.
• Copying an escaping choice from a different nesting location.

Sources & scope

Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic offline fixtures only; no account, permission, delivery or external-request operation is performed. RFC 3986 supplies the delimiter/data distinction; the query receiver in the fixture is explicitly invented, not a universal query grammar.

• Macros for custom creatives →Primary platform documentation or published technical standard · Supports: Supports placement-dependent macro escaping; the synthetic addresses and ownership ledger are original.
• RFC 3986: Uniform Resource Identifier (URI): Generic Syntax →Primary Internet standard · Supports: Section 2.4 supports separating components before decoding and avoiding repeated interpretation of the same representation. The invented query receiver and calculated strings are original.