TL;DR
One client asks why their Meta numbers read differently from another's, and the answer is that the two stores were set up months apart by two different people who each made reasonable choices. That is the real problem agencies have with tracking across a portfolio, and it is not a technical one. No conversion-tracking app gives you one place to configure and verify every client store, ours included: every install is independent, with its own settings and its own admin. What standardizes a portfolio is a written onboarding sequence, one verification pass you repeat without improvising, a naming convention nobody deviates from, and an ownership record you write on day one.
Key Takeaways
- Run the audit before the install. What already fires on a client store determines whether you are adding tracking or replacing it, and the answer changes the whole engagement.
- Keep one per-store record with pixel and dataset IDs, ad-account ownership, consent tooling, the theme developer's contact, and the install date. Nothing else in this article works without it.
- Use the same verification pass on every store, dated, with a named owner. Improvised checks are why two client stores drift apart.
- Standard event names only. Every custom event goes in a shared registry with the client name against it, or the taxonomy is gone within a quarter.
- Settle who owns the pixel, the dataset, and the ad account at contract signature. Offboarding is the worst possible time to discover the pixel lives inside your Business Manager.
- Re-verify after every client-side theme change, checkout upgrade, or app install, because app embeds get toggled off by developers who have no idea what they do.
- Each store's plan sits on that store's own Shopify bill, so a client leaving takes their subscription with them and a client arriving adds their own.
Start With an Audit, Not an Install
The first move on a new client is finding out what is already there, and most agencies skip it because the client said "we have nothing set up". They usually have a few tools installed at different times by different people.
Work in this order:
- Shopify admin → Settings → Customer events. Every app pixel and custom pixel registered through the Web Pixels API is listed here [1]. Screenshot it. This is your before state.
- Online Store → Themes → Customize → App embeds. Note every embed that is switched on, including ones nobody can identify.
- The ad accounts. In each platform, list the pixels or datasets receiving events and check which ones show recent activity. A dataset with traffic that nobody at the client can explain is usually a former agency's install still running.
-
The theme. Ask for the theme's git history if one exists, or at minimum ask whether anyone has pasted tracking code into
theme.liquid. Hardcoded pixels are a common source of duplicate events on client stores.
Only after those four do you install anything. How to run a pixel audit on Shopify is the long-form version of this pass and worth handing to whoever on your team does it.
One item for the same portfolio-wide sweep: Shopify's August 24, 2026 script-tag deprecation gives any app that delivers storefront JavaScript that way a dated failure [2]. Across a portfolio that is one pass, not fifteen separate emergencies.
What Goes in the Per-Store Record?
Everything you will otherwise have to rediscover. A shared sheet with one row per client is enough, and the discipline of filling it is worth more than the tooling around it.
| Field | Why it earns a column |
|---|---|
| Store domain and plan | Determines which Shopify surfaces exist on that store |
| Meta dataset ID, GA4 measurement ID, other platform IDs | The identifiers every debugging conversation starts with |
| Ad account owner | Client-owned or agency-owned, decided now rather than at offboarding |
| Business Manager the pixel lives in | The asset most often contested when an engagement ends |
| Consent tooling in use | Which banner, and whether it is wired to Shopify's Customer Privacy API |
| Tracking app and plan tier | What the client is paying for and what that tier includes |
| Theme developer contact | The person who will break your tracking without meaning to |
| Install date and last verification date | Turns "we should check that" into a sortable column |
The last column does more work than it looks like. Sort by last verification date and your audit queue writes itself, which matters at ten clients and is the whole job at forty.
The Repeatable Verification Pass
Same steps, same order, every store, whoever runs it. Our ten things to verify after install is the checklist itself, and there is no reason to restate it here. The agency-specific part is the wrapper around it.
Three rules make the checklist portfolio-grade. It is dated and signed, so the record names who ran it and when. It produces a short written result per item. And it runs on a trigger list: after install, after any theme change, after a checkout upgrade, after the client installs a new app, and on a fixed quarterly sweep for stores that had none of those.
The quarterly sweep is the one agencies drop first and regret. A store with no changes still drifts, because platforms change under it. A setup that was correct in March can be quietly wrong in September with nobody having touched the store.
How Do You Keep Event Naming Consistent Across Clients?
By refusing to be creative. Standard events only, with Purchase, AddToCart, and InitiateCheckout meaning exactly the same thing on every store you run, and custom events treated as exceptions that need approval.
Two conventions carry most of the weight. The first is a naming pattern for conversion actions inside each ad platform that encodes the source, so a conversion action for a server-side Shopify purchase is distinguishable at a glance from a legacy one somebody created in 2023. Whatever pattern you pick, it has to be identical across clients, because the value is reading an unfamiliar account without asking anyone.
The second is a registry of custom events: one row per custom event, listing the client, the trigger, the parameters, and who asked for it. Without it, the answer to "does this client track newsletter signups" becomes a research project.
Deduplication belongs in the convention too. Meta collapses events sharing an event_id for the same event name, received within a 48-hour window [3], and every store in your portfolio should be sending a shared ID between its browser and server streams. When a store double-counts, the first question is whether it followed the house pattern.
Who Owns the Pixel When the Engagement Ends?
Whoever the contract says. Settle it in the contract and the technical steps at offboarding become mechanical.
The failure mode is familiar: the agency creates the pixel inside its own Business Manager because that was faster during onboarding, spends two years building audiences on it, and then the client leaves. The client's event history and custom audiences now sit in an asset they do not own, and the negotiation is unpleasant for everyone.
The workable default is that the client owns the Business Manager, the ad account, and the pixel (dataset), and grants the agency partner access. Onboarding takes ten minutes longer and offboarding takes an afternoon instead of a month. Write it down at signature and record which Business Manager each asset lives in on the per-store row. A second, agency-owned portfolio pixel firing alongside the client's is a different thing and a legitimate one; when you need multiple pixels covers that setup.
Offboarding then has a real checklist: confirm ownership, or open the platform's transfer request if the asset sits in your business and assume it may not be grantable, which is why this was settled at signature. Then remove agency staff and collaborator accounts from the Shopify admin, hand over the per-store record with its verification history, and document what the incoming agency will find in Settings → Customer events. That last item costs you nothing and is the thing clients remember.
What Breaks When the Client's Dev Team Edits the Theme
App embeds get switched off, and it is invisible from the Shopify admin when they do. The person who did it will tell you truthfully that they did not touch your tracking, because from where they sat they were cleaning up unused toggles in the theme editor.
The rest repeats across clients: a theme swap that carries no app embed settings across, a checkout upgrade that changes which surfaces exist, a hardcoded pixel pasted into theme.liquid alongside your app to "make sure it works", and a consent banner replacement that stops passing signals the way the old one did. Each is invisible in the Shopify admin and visible immediately in the event stream, which is why the trigger list puts a verification pass after every one of them. Shopify's own defaults can change what a pixel is allowed to do with nobody editing anything, covered in why Shopify can pause your pixel.
What No App Does for You
Expect no cross-store dashboard, no config you author once and push to fifteen stores, and no single login that sees all your clients' event streams. Some apps bundle several stores onto one bill, which is a billing convenience rather than a standardization layer.
WeltPixel Conversion Tracking sits in the same place, and the architecture is deliberate: every install is independent, configured per store, and administered inside that store's own Shopify admin. Billing follows the same shape, one plan per store on that store's own Shopify bill [4]. An agency running fifteen clients has fifteen installs.
Per-store billing is neutral mechanics with one practical effect worth planning around: each store's plan sits on that store's own Shopify bill, so a client leaving takes their subscription with them. Conversion tracking for high-volume stores covers what per-store pricing means when order volume rather than store count is the variable.
Inside a single client with several storefronts you have a routing question rather than a portfolio question, and running a different pixel for each Shopify market covers it.
FAQ
Can one app manage conversion tracking across multiple Shopify stores?
Not as one configuration surface. Shopify apps install per store, and conversion-tracking apps carry their settings inside each store's admin, so there is no push-config feature to plan around. Some apps do bundle several stores onto a single bill, which helps accounting rather than standardization. The standardization comes from your onboarding process, your checklist, and your per-store record.
What should an agency check before installing anything on a new client store?
Four things, in order: Settings → Customer events for existing app pixels [1], the theme editor's App embeds list, the ad accounts for datasets already receiving events, and the theme itself for hardcoded tracking code. The before state determines whether you are adding tracking or replacing a duplicate.
Who should own the Meta pixel, the agency or the client?
The client, with the agency granted partner access. Agency-owned pixels create an ownership dispute at offboarding over audiences and event history that the client considers theirs. Decide it at contract signature and record which Business Manager each asset lives in.
How often should an agency re-verify a client's tracking?
On a trigger list plus a fixed sweep: after install, after any theme change, after a checkout upgrade, after the client installs a new app, and quarterly for stores with none of those. Platforms change under a store that nobody touched.
Does a client's developer need to know about the tracking setup?
Yes, specifically about app embeds. Switching off an unrecognized embed in the theme editor is a common way client-side work breaks tracking, and one sentence in the handover document prevents most of it.
If you want the same setup to install on every client store, with server-side delivery to GA4, Meta, TikTok, Google Ads, Reddit, Pinterest, Snapchat, and OpenAI ads and a plan that stays with the store when the engagement ends, install WeltPixel Conversion Tracking.
Start the per-store record this week, on the clients you already have. The onboarding sequence only pays once there is something to compare a new store against.
Sources
- Shopify Developers, "Web Pixels API", shopify.dev/docs/api/web-pixels-api, accessed August 26, 2026
- Shopify Developer Changelog, "Online Store script tags deprecation", shopify.dev/changelog/online-store-script-tags-deprecation, published August 24, 2026, accessed August 26, 2026
- Meta Developers, "Deduplicate Pixel and Conversions API events", developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events, accessed August 26, 2026
- WeltPixel Conversion Tracking, Shopify App Store listing, apps.shopify.com/weltpixel-conversion-tracking, accessed August 26, 2026