The real analytics problem for cross-border sellers isn’t dashboards — it’s drift
Most cross-border operators I talk to don’t have an analytics problem in the “we lack data” sense. They have a drift problem. The tracking plan that got documented in a Notion doc during launch week quietly diverges from the code that actually ships, and six weeks later nobody can explain why the checkout funnel shows a 40% drop between “add to cart” and “purchase” on one storefront but not another. That’s the thesis I want to test against Analytiics, a new product from maker Charlie Clark that launched into public beta on Product Hunt. It’s positioned as an analytics tool for app builders, not e-commerce operators, but the underlying mechanism — a tracking plan that lives in your repo as analytics.yaml, with CI checks that catch mismatches as your app changes — is exactly the missing piece in most DTC and marketplace stacks I audit. So this essay is less a product review and more a question: what happens when you steal this pattern and point it at Shopify, Amazon, and TikTok Shop?
What Analytiics actually solves, and why it’s not another GA4 wrapper
The pitch is deceptively small. You give your coding agent a one-line prompt — “Set up https://analytiics.co/ in this project” — and the agent reads your codebase, adds tracking for meaningful actions, and verifies the first events. You approve sign-in and review the diff. That’s it. No tag manager, no GTM container, no manual event mapping in a UI that looks like a 2014 spreadsheet.
The interesting part isn’t the setup. It’s what Clark calls the “after setup” — the tracking plan living in analytics.yaml alongside your code. That file powers typed event helpers, charts, and funnels. CI checks catch mismatches as your app changes, so tracking gets reviewed with the features it measures. You also get traffic analytics, customer journeys, Stripe revenue tracking, and a live visitor globe. Anonymous traffic uses no tracking cookies, and you choose which dashboard widgets to make public. The free plan includes one project and 25,000 events per month, and you can explore real traffic on the Thiings dashboard before connecting anything.
Compare that to the incumbent stack most cross-border sellers run. Shopify gives you basic Shopify Analytics plus whatever you bolt on — Klaviyo for email attribution, Triple Whale or Northbeam for multi-touch, GA4 for the “we have to have it” checkbox. Each of those tools has its own event taxonomy, its own naming conventions, and its own definition of what counts as a “purchase.” The drift isn’t between code and plan — it’s between five vendors and reality. Analytiics’ bet is that you collapse the taxonomy into one file that lives next to the code that fires the events. That’s a structurally different answer than adding a sixth dashboard.
Why Amazon sellers should care more than Shopify ones
Here’s the counterintuitive part. Shopify sellers can at least see their checkout funnel end-to-end because they own the storefront. Amazon FBA brand owners cannot. Amazon Seller Central gives you Business Reports, Brand Analytics, and the Amazon Attribution console, but the actual purchase event happens on Amazon’s domain, behind Amazon’s login, with Amazon’s session logic. You get a webhook-like report days later, aggregated, with no join key back to the anonymous visitor who clicked your Sponsored Brands ad. That’s the exact problem Lucas Centomo raised in the Product Hunt comments: he moved his pricing page to an embedded checkout running in a cross-origin iframe, so the “purchase” event never fires on his page — he only learns about it from a webhook later. He asked whether Analytiics can take a server-side event from that webhook and stitch it back to the anonymous visitor who clicked “Go Pro,” without cookies.
Clark’s answer is the most operationally interesting part of the whole launch thread. The browser endpoint ignores revenue on purpose — anyone can post to it — so a purchase event was never meant to fire on the page. The purchase comes from the provider, and the page’s only job is to leave a join key behind. Two paths: for signed-in users, call window.analytiics.identify(user.id) after signup/login, then pass that same id as client_reference_id (or metadata.analytiics_user_id) when your server creates the checkout session. Embedded checkout still creates the session server-side before the iframe loads, so the cross-origin part doesn’t matter. For anonymous visitors, read window.analytiics.session() on the pricing page, send it with your create-checkout request, and put it in the session’s metadata.analytiics_session_id. That credits the entry source of the visit that bought.
If the provider is Stripe, you don’t need any webhook code. Paste a restricted read-only key in project settings and it imports payments, refunds, and renewals every few minutes, reads that metadata, and credits the first visit. Add integrations: [stripe] to analytics.yaml so the repo says where revenue comes from, and analytiics check will warn if the manifest and the connection disagree. For any other provider, your webhook handler sends the purchase with the server SDK, using revenue() with eventId: event.id so replays don’t double count. The drift check scans server-side track({ name }) calls too, so a purchase event marked revenue: true in the manifest is satisfied by the webhook code, not the page. Codegen won’t even give you a browser call for it.
That’s a genuinely correct architecture for the cross-border attribution problem, and it’s worth stealing even if you never sign up. The pattern — browser endpoint strips revenue, server endpoint carries it, join key bridges the two — is how you should be thinking about every marketplace where you don’t own the checkout. Amazon, TikTok Shop, Temu, SHEIN, Etsy, eBay — all of them are cross-origin iframes from your attribution’s point of view. The question is whether you have a join key.
Where the math breaks
Clark is honest about one limit, and it matters more for cross-border than for domestic: anonymous ids rotate daily, so a visitor who browses Monday and buys Wednesday without ever being identified gets credited to Wednesday’s session, not Monday’s. For a US DTC brand with same-day conversion windows, that’s a rounding error. For a cross-border seller shipping to markets where consideration windows run a week or two — think high-AOV furniture, B2B wholesale, anything with customs friction — that’s a structural undercount of upper-funnel spend. You’ll systematically over-credit the last touch and under-credit the ad that started the journey. If you’re running Meta Ads or TikTok Ads into those markets, you’ll cut the wrong campaigns.
The other gap: Analytiics is built for apps, not storefronts. There’s no native Shopify app, no Amazon SP-API connector, no TikTok Shop integration. You’d be wiring this yourself via the server SDK and your own webhook handlers. For a technical DTC operator with an in-house dev, that’s a weekend. For a seller running a seven-figure Amazon business off spreadsheets and a VA, it’s a non-starter. The free plan’s 25,000 events per month also won’t survive a real storefront — a mid-size Shopify store burns that in a day. You’re looking at a paid tier that isn’t disclosed on the launch page, which is fine for a beta but means you can’t model the unit economics yet.
The naming convention question nobody answered
Blair asked the sharpest question in the thread: if the agent creates the event names themselves, won’t the notation end up being inconsistent? Can you provide the naming conventions in advance? Clark didn’t answer that one publicly in the source material. That silence is the tell. The whole value proposition rests on analytics.yaml being a stable contract, and if the coding agent invents add_to_cart in one PR and AddToCart in another, the CI checks catch the mismatch — but only after you’ve shipped the inconsistency. You’d want to seed the manifest by hand before letting any agent touch it, then treat the file as read-only for agents and writable only through human review. That’s not a flaw in the product so much as a governance requirement the launch copy doesn’t emphasize.
Compare this to how Segment handles the same problem. Segment’s Tracking Plan feature lets you define event schemas in a UI, then enforce them via Typewriter and Protocols. It’s more mature, more expensive, and lives outside your repo. Analytiics’ bet is that the repo is the right home for the contract, which is a defensible position for teams that already treat infrastructure as code. For cross-border operators running multi-storefront setups — one Shopify store, one Amazon storefront, one TikTok Shop — the repo-as-contract model has a real advantage: you can version the tracking plan per market, branch it, and review changes alongside the localization work that changes the funnel in the first place.
What cross-border sellers can borrow from this launch
Three patterns worth stealing this week, regardless of whether you adopt the tool:
1. Put your tracking plan in version control. Whether it’s analytics.yaml or a tracking-plan.md in your repo, the plan should live where the code lives, not in a Notion doc that nobody updates. Every event your storefront fires — view_item, add_to_cart, begin_checkout, purchase — should have a documented name, trigger, properties, and owner. If you’re on Shopify, you can do this with Shopify Web Pixels and a custom pixel app; if you’re on Amazon, you document what you can observe from Amazon Brand Analytics and accept the gaps.
2. Separate browser events from revenue events. The browser endpoint should never carry revenue. Anyone can POST to it. Revenue events should come from your payment provider or your marketplace’s server-side report, joined back via a session id or user id you control. This is the single biggest fix for cross-border attribution, and it applies whether you’re on Stripe, Adyen, Checkout.com, or a marketplace’s native payment rail.
3. Run a drift check in CI. Even a simple script that greps your codebase for track( calls and compares them against your manifest would catch the most common failure mode: a developer adds a new event, ships it, and forgets to document it. Analytiics does this natively with analytiics check. You can approximate it with a GitHub Actions workflow and a YAML linter in an afternoon.
The Stripe integration is the sleeper feature
Of everything in the launch, the Stripe read-only key import is the one I’d test first. It imports payments, refunds, and renewals every few minutes, reads the metadata your server attached to the checkout session, and credits the first visit. For a DTC brand running Stripe on a custom storefront, that’s a near-zero-effort way to close the loop between ad click and revenue without building a webhook pipeline. For a Shopify seller, Stripe is often the underlying processor via Shopify Payments, but the metadata you need may not propagate cleanly — that’s a test, not an assumption. For Amazon sellers, Stripe is irrelevant; you’re stuck with Amazon’s reporting latency and aggregation. This is where the tool’s app-builder DNA shows: it’s optimized for the Stripe-shaped world, which is the DTC world, not the marketplace world.
Where my judgment says it falls short
Three concerns, in order of severity.
First, the anonymous id rotation is a real ceiling for cross-border. Clark flags it honestly, but the launch copy doesn’t quantify the impact. If your average consideration window is under 24 hours, you’re fine. If it’s over 48 hours, you’re systematically misattributing. For anyone selling into markets with longer decision cycles — think B2B, high-AOV, or anything requiring customs clearance — this is a material limitation, not a footnote.
Second, the app-builder framing means the e-commerce use case is DIY. No Shopify app, no Amazon connector, no TikTok Shop integration. The server SDK and webhook pattern are correct, but you’re building the bridge yourself. That’s fine for a technical team; it’s a dealbreaker for a lean operator.
Third, the pricing beyond the free tier is not disclosed on the launch page. The free plan’s 25,000 events per month is a developer-tier number, not a storefront number. Until paid pricing is public, you can’t model whether this beats PostHog, Mixpanel, or Amplitude on cost-per-event for a real storefront. My guess is it lands somewhere between PostHog’s self-hosted economics and Amplitude’s enterprise pricing, but that’s a guess, not a sourced fact.
What I’d watch / test next
This week, before you sign up for anything, do three things. First, audit your current tracking plan — wherever it lives — and count how many events fire on your storefront that aren’t documented anywhere. That number is your drift debt. Second, check whether your payment provider passes a session id or user id you can join back to your analytics. If it does, you have the join key; if it doesn’t, that’s your next engineering ticket. Third, if you’re technical, spin up the Analytiics free plan on a side project — not your main storefront — and run the coding-agent setup prompt against a small app to see how the analytics.yaml manifest behaves when the agent invents its own event names. That’s the governance question Blair raised and nobody answered. Watch whether Clark ships a naming-convention feature or a Shopify app in the next 60 days; either would signal the product is serious about e-commerce rather than just adjacent to it. If neither lands, steal the pattern and build it yourself — the architecture is the valuable part, and it’s now public.
