Read and install the landing-page helper block

What it is and why

The block you copied in Get the landing-page helper block has three parts that belong on every page of the advertiser’s site, plus one easq('track', …) line per conversion step that belongs where that step happens. This page reads the block part by part and shows where each goes — pasted into the site template, or split across two Google Tag Manager tags. It is the second stage of Install the landing-page helper.

Example. A two-step funnel block for registration and first_deposit goes into the site’s <head>, so every page captures the click id when a visitor lands from an ad. The easq('track', 'registration') line moves to the “account created” screen and easq('track', 'first_deposit') to the deposit receipt. Both report against the click id the config call stored when the visitor landed.

Typical scenarios

You want	Do	Where
Install the block on a site whose template you can edit	Paste the stub, the script tag and the config call into the template; move each track line to its step	the site’s <head> or the top of <body>
Run it through Google Tag Manager	Tag 1 (All Pages) carries the stub, config and script; one Tag 2 per step, or one driven by {{Event Name}}	GTM, Custom HTML tags
A site with a strict Content-Security-Policy	Allow the script host in script-src and the config host in connect-src	the advertiser’s CSP header

Step by step

Read the block

A generated block has three parts. This is the HTML shape; the Google Tag Manager shape carries the same three parts split across tags. The example is a two-step funnel block — a single-action block is the same shape with one entry in actions and one track line.

<!-- The landing URL in the creative must carry the click id:
     https://yourlanding.com/product?easclid=$$CLICK_ID$$ -->
<!-- Epom conversion tracking - on EVERY page, before your own scripts -->
<script>window.easq=window.easq||function(){(easq.q=easq.q||[]).push(arguments)};</script>
<script async src="https://ads.example.com/easq.js"></script>
<script>
easq('config', {
  host: 'https://ads.example.com',
  network: '17',
  payoutOverride: false,
  actions: {
    'registration': ['b21f0c9d4e7a3f5182c6d0ab94e7f331'],
    'first_deposit': ['7c4a1e08b5d29f63a0e1c74b8d2f5069']
  }
});
easq('arbitrate', 'last-click');
</script>

<!-- One line per funnel step, where the step happens -->
<script>easq('track', 'registration');</script>
<script>easq('track', 'first_deposit');</script>

1. The stub (window.easq=window.easq||…) queues calls made before the script has finished loading. It must come first.
2. The script tag loads easq.js. It is async, one static file, identical for every network, and safe to cache.
3. The config call registers the ad-serving host and the event dictionary — and, as a side effect, captures the click id from the current URL. That is why the block belongs on every page: the landing page needs it to store the click, and the conversion page needs it to read the click back.

The easq('track', …) lines are the conversion. Put each one where that step actually happens, not where the block sits.

Install it — plain HTML

1. Paste the first three parts into the site template, in <head> or at the top of <body>, ahead of your own scripts, so it is present on every page.
2. Move each easq('track', …) line to the page or moment where that step completes — the order-confirmation page, the “account created” screen, the deposit receipt.
3. If the site runs a Content-Security-Policy, allow two origins — see Caveats.
4. Check the result with easq('debug') on the landing page after a live click — see Check and troubleshoot the landing-page helper.

Install it — Google Tag Manager

The Snippet tab’s Google Tag Manager format splits the same thing into two tags:

1. Tag 1 — Custom HTML, trigger All Pages. The stub, the config call and the script tag.
2. Tag 2 — Custom HTML, one tag per funnel step, triggered by the event for that step. It holds the single easq('track', …) line.

The generated block also offers an alternative to a tag per step: one Tag 2 for everything, with the event name coming from a GTM variable.

<script>easq('track', '{{Event Name}}');</script>

On a campaign that takes a payout from the page, the generated line carries one too:

<script>easq('track', '{{Event Name}}', { payout: {{Order Value}} });</script>

{{Order Value}} there is a placeholder, and the name is a trap: what belongs in the payout field is the price of the conversion, which is almost never the order total — see Send a payout. Point it at the variable that holds the price before you publish the tag.

Once the block is on every page, fire each step where it happens — see Fire a conversion per funnel step — and check the result with easq('debug') — see Check and troubleshoot the landing-page helper.

Caveats and exceptions

The block goes on every page. It is not a conversion tag — the config call is what captures the click id when the visitor lands, and a copy that appears only on the order-confirmation page will store nothing and report no-clickid forever.

The arbitrate line is not the once-per-click rule. easq('arbitrate', 'last-click'); sits in the same <script> as the config call, and it is there by default: Count one conversion per click is ticked when the tab opens, and only unticking it takes the line out. It settles which of two of your own ad-serving domains on one landing page gets the conversion — the later click wins. Despite the name of the checkbox, it has nothing to do with the once-per-click rule in Fire a conversion per funnel step. On a page running a single ad-serving domain it changes nothing.

The block may appear twice; the config call may run on every page view. The second copy of the script starts no second runtime — the file returns immediately when it finds one already loaded — and the second copy’s config and track calls simply run against the runtime that is there. Calling easq('config', …) more than once for the same host merges rather than duplicating — new event names are added.

easq('track', …) is safe to fire before the script has loaded — but not before the stub. The stub queues it, and the runtime applies every queued config before any queued track. The stub has to have run, though: it is the first line of the block, and of Tag 1 in the tag-manager shape. In GTM, a step tag that runs before Tag 1 throws easq is not defined and the conversion is lost with no diagnostic anywhere. The All Pages trigger normally settles it — Tag 1 runs on the page view, the conversion events come later. Where a step’s trigger is the same GTM event as All Pages, though — a Page View trigger scoped to /thank-you, say — nothing orders the two, so give Tag 1 a higher firing priority, or make it the step tag’s setup tag.

In GTM, quote a text variable, never a number. A tag manager pastes a variable’s value straight into the source, so an unquoted string is a syntax error that kills the whole tag. (A quoted number still prices correctly; it is simply not the shape the generated block emits.) The generated block already has the quoting right for your campaign; copy it rather than retyping it.

Content-Security-Policy: two origins, not always the same host. The one named in the <script src> belongs in script-src, and the host from the config call belongs in connect-src, because the conversion is a credentialed fetch to it. A network with a CDN in front of its ad-serving domain generates a block naming the CDN in the script tag and the serving domain in host. That is correct — allow both rather than editing host to match. A third origin comes into it only if your network mirrors conversions to third-party trackers (see Piggyback pixels): those tags come back with the counted conversion and are written into a hidden same-origin frame, so the advertiser’s own policy governs them and a strict one will block them.

The caveats that apply to the helper as a whole — who can do this, what the block stores and where the stored click id is readable — are on Install the landing-page helper.

Not working?

Symptom	Check	Where
no-clickid although the landing URL is tagged	The block is on the conversion page only, not the landing page; or checkout runs on another registrable domain (a payment provider).	view-source of the landing page; the checkout’s domain
easq is not defined in the console (GTM)	Tag 2 fired before Tag 1 on the same trigger.	Tag 1’s firing priority / setup tag in GTM
The whole GTM tag fails with a syntax error	An unquoted text variable in the track line.	the step tag’s HTML
A payout never applies	The campaign ignores page payouts, or {{Order Value}} points at the order total.	the payout from the page line of easq('debug'); the GTM variable
The conversion request is blocked	The site’s CSP lacks script-src for the script host or connect-src for host.	the browser console’s CSP errors; the advertiser’s CSP header

A click id that never arrives is on Get the landing-page helper block; the rest is on Install the landing-page helper. For the reason codes and the console checks, go to Check and troubleshoot the landing-page helper.

Reference

The three parts of the block, in brief, are tabled under Reference on the hub; every command and option is on Landing-page helper reference.

Related pages:

• Install the landing-page helper
• Get the landing-page helper block
• Landing-page helper reference
• Check and troubleshoot the landing-page helper
• Piggyback pixels
• Save a conversion funnel and report on it