Troubleshooting

#The button does nothing

The call to action still points at #utmcap, or at a literal /out/{utmcap_id}, and pressing it goes nowhere.

Check the tag version first. The tag is cached, so a fix that is live on the server but not yet in your browser looks exactly like a fix that does not work:

window.utmcap.version   // should be '8'

If that is old, hard-refresh, or add ?x=1 to the page address.

Then check whether the tag has a click id at all:

window.utmcap.clickId       // null means it could not open one
window.utmcap.tagCampaign   // the campaign this page declares, '' if none

If clickId is null, nothing named a campaign, and that is the tag working as intended rather than failing. It needs one of two things, and it does not guess:

• utm_id=<alias> on the URL the visitor arrived on. Take the Final URL from the campaign's Tracking tab rather than editing one you already have; a plain landing page address pasted into the ad platform has no utm_id in it.
• or &c=<alias> on the tag's own src, for a page whose own visitors should belong to a campaign — the campaign tag. If tagCampaign is empty, this page is carrying the universal tag.

A page used by more than one campaign can only be named by the URL, so a visitor reaching it with no utm_id has an inert button by design. See when two campaigns share a lander.

Earlier tags matched the page's own address against your registered landing pages instead, so a trailing slash or a missing www on the saved landing page URL could break this. That is no longer what decides it.

If clickId is set and only the pasted /out/{utmcap_id} is unfilled, that is deliberate:

window.utmcap.fromRedirect   // false = no redirect brought this visitor

{utmcap_id} is a redirect macro and fills only where a redirect happened. Under parallel tracking use #utmcap — see the call to action.

#The button worked, then stopped, then worked again

Almost always the thirty-minute session window, met without a cookie.

One visitor per campaign gets one click per thirty minutes. That is enforced by the tag's cookie and by the server. If you test from a private window, or after clearing cookies, you arrive inside your own earlier window with nothing to identify you — and the server hands back the click id it already issued rather than a new one. The button works and no second click is counted.

If you are seeing a genuinely dead button on a repeat visit, check the tag version: this behaviour arrived in version 5's predecessor and older cached copies answered with nothing.

#Clicks are counted against the wrong campaign

Two campaigns on one landing page, and the traffic of one showing up under the other.

Open the campaign's Tracking tab and look for the orphan warning. If it is there, the Final URL in your ad has lost its utm_id — see parallel tracking. Fix the ad, and add the campaign tag so the page names the campaign even if the URL loses it again.

If there is no warning, check which tag that page carries. A page holding one campaign's tag, &c=<alias>, attributes every visitor who arrives without utm_id to that campaign — which is what it is for, and wrong if a second campaign also uses the page. Put the universal tag on a shared page, or give each campaign its own landing page URL. See when two campaigns share a lander.

#Every click records zero cost

The traffic source has no cost macro, or the Final URL was assembled by hand and the macro is spelled wrong.

A macro that is almost right substitutes nothing, and a click with no cost records as free. Take the URL from the Tracking tab rather than editing one you already have — that is the only version with the chosen source's macros in it.

Both halves have to be set on the source and they have to agree — the macro the platform writes, and the parameter UTMCAP reads it from. See cost.

#No conversions are arriving

Work backwards along the chain:

1. Does the offer URL carry the click id? It needs {utmcap_id} somewhere in it, so the network knows which click to name.
2. Has the network been given your postback URL? It is on the campaign, and it has to be configured on their side.
3. Is the network firing it? Most networks show a postback log. A conversion they never sent cannot arrive.
4. Check Gateway events in the app for what did arrive and what was done with it.

A conversion for a click id that does not exist here is recorded and marked, rather than dropped — so if the network says it fired and you see nothing, the id it sent is the thing to compare.

#Conversions arrive but revenue does not

Open the conversions log and read Status.

Only approved conversions become revenue. A column of pending on a network that has approved everything is not an approval delay — it is a status word the mapping does not recognise, held as pending rather than guessed into revenue. Map it on the network and the conversions arrive as what they are. See the four states.

#The numbers do not match the ad platform

Three ordinary causes before assuming a bug:

• Bots are excluded here and counted there. The clicks log shows which signal excluded each one.
• A click and its conversion can fall in different date ranges. A click is counted the day it happened; a conversion the day it arrived. Widen the range before looking further — see which date a row falls under.
• Cost is missing, so ROI looks impossible. See above.

#The page shows old data

Clicks are recorded as they happen. Two things are cached deliberately:

• A tenant's plan and limits for about a minute.
• The map of landing page addresses to campaigns for five minutes — so a landing page URL you have just changed takes up to five minutes to be recognised at its new address.

Everything else is read live over the date range on the screen. If a number looks stale beyond that, check the range picker before anything else.

#Still stuck

Write to [email protected] with the campaign alias and, if it is a landing page problem, the exact address a visitor reaches. Those two facts answer most of it.