The analytics stack is quietly becoming the creator economy’s real bottleneck
Most creators and social media operators I know don’t have a data problem. They have a tracking-plan problem. You can pull reach, impressions, and saves from every native dashboard, but the moment you try to answer “which post actually drove the signup,” “which link in the bio turned into revenue,” or “which platform’s audience converts instead of just scrolls,” the numbers fall apart. Attribution breaks at the exact seam where content meets product. So when a maker shows up on Product Hunt pitching analytics that live in the repo, next to the code, with a versioned tracking plan and CI checks, I pay attention — not because I’m going to ship an app this week, but because the underlying idea (a declarative, reviewable source of truth for what you measure) is exactly what most creator stacks are missing. That’s the lens I want to write through today.
What Analytiics actually is, and why the framing matters
The maker, Charlie Clark, opened the launch with a line that’s doing more work than it looks like: “analytics should be part of the way you build your app.” The pitch is that you hand your coding agent a single 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 changes. That’s the setup story. The interesting part, per the maker, is what happens after setup: your tracking plan lives in analytics.yaml, alongside your code, and that file powers typed event helpers, charts, and funnels. CI checks catch mismatches as the 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 public beta is open to everyone; the free plan includes one project and 25,000 events per month, and you can poke at real traffic on the Thiings dashboard before connecting anything.
My take: this is not a social media scheduling tool. It’s a product analytics tool. But the reason it belongs in a creator-economy conversation is that the boundary between “content tool” and “product tool” has basically dissolved for anyone running a paid community, a course, a newsletter with a paywall, a link-in-bio storefront, or a SaaS-adjacent creator business. If you’re a social media operator whose job ends at “post the thing and report the numbers,” you can skim this. If your job is “post the thing and prove it moved revenue,” read on.
The real problem: tracking plans rot faster than content calendars
Every analytics setup I’ve ever inherited had the same failure mode. Someone installed a pixel, named events on the fly (signup, sign_up, SignUp, user_registered), and then six months later nobody could tell which event was canonical. The dashboards kept rendering, which is the dangerous part — they look healthy while quietly measuring different things than the team thinks. In the launch thread, Lucas CENTOMO nailed this exact pain: “every analytics setup I’ve had drifted from the code within a month.” That’s not a nitpick, that’s the whole thesis. Drift is the default state of analytics, not the exception.
The Analytiics answer is to make the tracking plan a file in the repo and let CI complain when the code and the manifest disagree. I’ve watched this pattern play out in adjacent domains — infrastructure-as-code, design tokens, schema migrations — and the pattern is always the same: once the source of truth is reviewable in a pull request, drift stops being invisible. That’s the part I’d actually use, and it’s the part I’d steal conceptually even if I never touch the product.
Where the math breaks (and where it doesn’t)
Here’s the honest caveat, straight from the thread. Blair asked a sharp question: if the agent creates event names itself, won’t the notation end up inconsistent? Can you provide naming conventions in advance? That’s the obvious failure mode of any “let the agent wire up your tracking” workflow — LLMs are great at producing plausible event names and terrible at producing consistent ones unless you constrain them. The maker didn’t dodge it, but the answer isn’t fully spelled out in the scrape beyond the existence of the analytics.yaml manifest and the drift check. My read: the manifest is the naming convention, and the CI check is what enforces it. Whether that’s enough in practice depends on how opinionated the defaults are, which I can’t verify from the source.
Then there’s the attribution limit the maker volunteered, unprompted, which is the kind of thing that earns trust in my book. Anonymous IDs rotate daily. So a visitor who browses on Monday and buys on Wednesday without ever being identified gets credited to Wednesday’s session, not Monday’s. That’s a real hole in multi-day consideration funnels — exactly the kind of funnel that matters for creator businesses, where someone discovers you on TikTok, lurks for a week, and buys after a newsletter. The maker frames it as “one honest limit,” and I’d frame it the same way: it’s a limit, not a dealbreaker, but if your conversion window is longer than 24 hours and you’re not identifying users before purchase, you’re going to misattribute a chunk of revenue.
How it stacks up against the tools creators already pay for
If you’re a social media operator, your current stack probably looks like one of these:
- Metricool or Later for scheduling and native-platform analytics across Instagram, TikTok, YouTube, X, LinkedIn, Facebook, Threads, and Pinterest.
- Buffer or Hootsuite if you’re in an agency or team context and need approvals and shared inboxes.
- Google Analytics 4 for on-site behavior, usually bolted onto a link-in-bio tool and a Stripe or Gumroad checkout.
- A spreadsheet, notionally, for the “which post drove which sale” question that nobody actually answers.
The gap Analytiics is aiming at isn’t scheduling or native-platform reporting — it doesn’t do either, as far as the source shows. It’s the seam between your content and your product, which is precisely where GA4 gets muddy and where native platform dashboards give up entirely. GA4 will tell you a session happened; it will not tell you that the session came from a specific TikTok video, because TikTok doesn’t pass that context cleanly and GA4’s attribution model is a black box most operators don’t have time to audit. A declarative tracking plan in the repo, with server-side revenue events and a Stripe integration that reads metadata to credit the first visit, is a genuinely different approach to the same question. Whether it’s better depends on how much of your funnel happens on a domain you control.
Why TikTok and Instagram creators should care more than LinkedIn ones
This is the part I’d flag hardest for operators. If your business lives entirely inside a platform — you monetize via Reels bonuses, TikTok Shop commissions, or brand deals brokered in DMs — Analytiics does nothing for you. Your conversions happen on someone else’s infrastructure and you’ll never get server-side events for them.
But if you’re the creator who runs a link-in-bio storefront, a paid Substack or Beehiiv newsletter, a Circle community, a Kajabi course, or a small SaaS built on top of your audience, the calculus flips. Your revenue does happen on infrastructure you can instrument. The problem is that most creators instrument it badly — a GA4 tag and a hope. A tracking plan that lives in the repo, with typed event helpers and CI checks, is overkill for a solo creator who posts twice a week. It’s the right shape for a creator who’s shipping product changes weekly and needs to know whether the Tuesday Reel or the Thursday newsletter drove the upgrade.
The public-dashboard angle is underrated
One detail in the launch that I think gets glossed over: you choose which dashboard widgets to make public, and the maker points to real traffic on the Thiings dashboard as a live example. For indie founders and creators, a public analytics page is a trust signal — it’s the same move Buffer made with its transparency reports and that Baremetrics popularized with public MRR dashboards years ago. If you’re selling a course or a community and you can show real, live traffic and revenue numbers on a public page, that’s a conversion asset, not just a vanity toy. The catch, obviously, is that you have to be willing to show the numbers. Most creators won’t be. The ones who will are the ones who already have something to brag about.
Where my judgment says it falls short
I want to be careful here, because the source is a Product Hunt launch thread and not a full product teardown. So treat everything in this section as my take, not as verified fact.
- It’s a product-analytics tool, not a social tool. If you were hoping for cross-platform post-level reporting, scheduling, or content repurposing, this isn’t it. The platform coverage in the source is about your app’s traffic, not about Instagram vs. TikTok performance.
- The agent-driven setup is the riskiest part. Blair’s question about naming consistency is the right one, and the answer in the thread is more “trust the manifest” than “here’s how we prevent it.” I’d bet the first month of real usage produces a wave of messy event names that users then have to clean up — which is exactly the drift problem the product claims to solve, just moved one step earlier.
- The 24-hour anonymous ID rotation is a real limitation for creator funnels, which tend to be long and multi-touch. If you’re not calling
identify()before purchase, you’re going to lose attribution on anyone who doesn’t buy same-day. - Pricing beyond the free tier is not disclosed in the source. The free plan is one project and 25,000 events per month, which is generous for a side project and tight for anything with real traffic. I’d want to see the paid tiers before recommending it to a team.
- Stripe is the only named revenue integration. The maker describes a server-SDK path for “any other provider,” which is fine, but it means non-Stripe creators are doing more work. If you’re on Paddle, Lemon Squeezy, or Gumroad, expect to write your own webhook handler.
- No mention of GDPR/CCPA posture beyond “anonymous traffic uses no tracking cookies.” That’s a good start, but “no cookies” isn’t the same as “compliant,” and for creators selling to EU audiences, the consent story matters. The source is silent on it.
Who this is not for
If you’re a pure social media manager — you run accounts for clients, you report on reach and engagement, you never touch a checkout — Analytiics is not your tool. Stay on Metricool, Later, or Buffer. If you’re a creator whose entire monetization runs through platform-native features (TikTok Shop, YouTube AdSense, Instagram bonuses), this also isn’t for you, because you can’t instrument the conversion. And if you’re a solo creator shipping nothing but content, the tracking-plan-in-repo model is a solution to a problem you don’t have yet.
Where it does fit: the creator-founder hybrid. The person who has an audience, a product, and a growing suspicion that their analytics are lying to them. That person is underserved by both ends of the market — social tools don’t go deep enough, and enterprise product analytics tools like Mixpanel or Amplitude are priced and shaped for teams, not for someone who also writes the newsletter. The repo-native, agent-assisted, CI-checked model is a genuinely interesting middle path, and I’d bet we see more tools in this shape over the next year.
What I’d watch / test next
If you’re an operator reading this and you want to do something concrete this week, here’s what I’d actually do — not “sign up for another tool,” but “steal the pattern.”
First, write down your tracking plan. Literally, in a file. List every event that matters to your business — viewed_pricing, started_checkout, purchased, subscribed, upgraded — and give each one a canonical name and a one-line definition. If you can’t do this in twenty minutes, that’s the finding. Your analytics are already drifting and you didn’t notice.
Second, pick one funnel and instrument it end-to-end this week. Not all of them. One. From the social post that drove the click, through the landing page, to the checkout, to the confirmation. Use UTM parameters religiously and check that your checkout provider passes them through. If you’re on Stripe, test whether metadata survives the round trip.
Third, if you want to evaluate Analytiics specifically, do it on a throwaway project first. The free plan gives you one project and 25,000 events, which is enough to run a real test. Look at the public Thiings dashboard to see what the output actually looks like before you commit. And read the Stripe docs and SDK docs the maker linked — those are where the real behavior lives.
Fourth, ask the question the maker asked at the end of the launch: what’s the first question you’d want analytics to answer about your app? For most creators I know, the honest answer is “which piece of content actually made me money.” That question is answerable. It’s just not answerable with the tools most of us are using. Whether Analytiics is the answer or just the start of a better conversation, the conversation is worth having.
