WhatsApp Us Now
Most ecommerce brands do not need one permanently. They need one for a defined piece of work, and a specific event usually triggers it: a replatform, purchase events firing twice or not at all, a consent banner that quietly blocked tags, or a move to server-side tracking. Scoped project, named deliverables, then out.
What actually justifies bringing one in?
Five situations, and outside them a container is usually better left alone. A replatform or a theme change, because tags bound to old selectors and old checkout steps stop firing silently and nothing in the interface announces it. Purchase events firing twice, or not at all, which surfaces as reported conversions that no longer match the orders in your back office. A consent banner installed by somebody else, which can block tags on load and leave a clean-looking container that is collecting nothing from a good share of your traffic. A container nobody has audited in years, grown by accretion: tags added by successive agencies and contractors, none ever removed, several quietly duplicating each other. And a move to server-side, where deduplication between browser and server events has to be exactly right or the same purchase gets counted twice. Two of those tend to arrive together, since a replatform is usually when consent tooling gets swapped as well.
What should the engagement produce?
Three deliverables, and it is fair to ask for all three in the scope before anything is signed. A documented container: every tag, trigger and variable listed with what it is for and who asked for it, so the next person does not inherit a mystery. A tagging plan tied to the events the business actually reports on, which is usually a much shorter list than what is currently firing, because containers accumulate events nobody has looked at since the week they were built. And a reconciliation: a defined window of live orders counted in the back office against conversions reported in each platform, with the gaps explained rather than averaged away. Ask as well for the handover to be written for somebody who is not a specialist, because whoever maintains this in a year is more likely to be your operations lead than an engineer. If a proposal leaves out that last one, it is a setup job rather than a fix, and you will not know whether it worked. That is the work a google tag manager consultant should be scoped against.
Why is this project work rather than a retainer?
Because the work has an end. Once the container is documented, the plan matches what the business reports on, and live orders reconcile against reported conversions, very little recurs until something changes. The exceptions deserve naming: a brand shipping frequent site changes, or running a large server-side setup, does have ongoing tagging work and may reasonably want somebody on call. Most brands do not, and a monthly fee for a container that changes twice a year is money that would do more elsewhere. What does not change is where this sits in the order of operations. Tag setup is upstream of every number in every report you use to make decisions. Budget shifts, creative reads, channel comparisons: all of it is downstream of whether events fire once, at the right moment, with the right values attached.
That upstream position is why we insist on it early. With an athletic apparel brand, sales rose 35.7% year to date to $9.27M while paid media investment rose 42% year over year and blended ROAS held at 3.36x across six months, a deliberate choice to scale rather than squeeze efficiency, measured on blended ROAS rather than platform-reported ROAS.
If your tag setup has grown by accretion, Plaid Testing’s free thirty minute audit starts there: what is firing, what is duplicated, and three fixes worth making first.
