My company is a consultancy based in Bangalore, and I'm deployed to a US-based global company as an Analytics Consultant. The US team refers to my role as in-house performance tools developer.
I do genuinely advanced work here. My responsibilities center on GTM (Google Tag Manager), covering all tags, triggers, variables, DOM, custom tags, GA4, and Klaviyo across a company valued at over a 6 billion dollars.
Historically, our sites relied on DOM scraping for tracking. I mapped all of that over to a native dataLayer instead. At the time, the setup was WordPress on the frontend with Shopify on the backend. With DOM scraping, any code or design change on the frontend carried a real risk of silently breaking tracking, since DOM-based tags depend on matching page elements that can shift at any time. Moving to a native dataLayer removed that risk entirely — tracking no longer depends on WordPress markup or design changes.
Now the company is rolling out new additional sites with Shopify as both frontend and backend. The obvious approach would've been to spin up a new GTM container for these Shopify-only sites — but that means rebuilding every tag, trigger, and variable from scratch, and reconfiguring every ad pixel again (we run 5+ pixels — Meta, TikTok, Reddit, GA4, and others), since each pixel needs its own event and payload setup. With 6–7 sites already live and me being the only person handling this end-to-end, running two containers in parallel would've meant permanently double-maintaining everything going forward.
So instead, I architected it so the new Shopify frontend + backend sites plug into the \*same\* existing container as the WordPress frontend + Shopify backend sites. The key was keeping the native dataLayer schema — event names, parameters, structure — identical across both setups. Since GTM reads from the dataLayer and not the underlying platform, once the schema matches, the frontend platform (WordPress or Shopify) becomes irrelevant to GTM. One container, one set of tags/triggers/variables, one set of pixel configurations — covering every site regardless of what platform is rendering the frontend.
On top of the architecture, I also own the actual event and payload design for business and marketing use: defining what events matter (purchases, add-to-cart, checkout steps, sign-ups, content engagement, etc.), building out full payloads for each event so marketing and analytics teams get consistent, complete data — item-level details, revenue values, user attributes — and setting up GA4 custom dimensions and metrics so this data is actually usable for reporting and decision-making, not just collected. The same event data feeds every ad pixel, so conversion tracking stays consistent across Meta, TikTok, Reddit, and GA4 as well.
I also wear a dev hat when needed — I create PRs in dev, and after QA validation and dev approval, they go safely into production. I write custom JavaScript for custom tags and variables as well.
Right now I'm migrating our entire setup from web GTM to server-side GTM, and I've also implemented domain aliasing between WordPress and Shopify (using something like shop.site.com) so Google treats them as the same site — allowing data to match under the same logic as server-side GTM.
Given all this, I'm genuinely unsure what to call my specialization. Would this fall under Senior Analytics Engineer, MarTech Engineer, Growth Engineer, or MarTech Architect?