Install on Shopify
Sign up for a 30-day Free Trial.
index_mail_icon
Aimerce Blogs
Hydrogen vs. Custom JS: How Headless Tracking Differs
10 August 2026
Hydrogen vs. Custom JS: How Headless Tracking Differs
First-Party Data 101

Quick Answer: Hydrogen is Shopify's own headless framework, so tracking has real scaffolding to build on. Custom JS frameworks like Next.js have none, every event has to be wired up by hand. Check your package.json for @shopify/hydrogen to know which one you're actually dealing with, since the fix is different for each.

Key Takeaways

  • Hydrogen is Shopify's own headless framework, running on the Storefront API and usually Oxygen, which keeps you inside Shopify's ecosystem even without a Liquid theme. Custom JS frameworks like Next.js, Remix, or Nuxt use Shopify as a backend only, with nothing pre-built for tracking.
  • Check your package.json for the @shopify/hydrogen dependency to know which one you're actually dealing with before writing any tracking code, since the right fix is different for each.
  • Hydrogen breaks when developers ignore its built-in components and slap in generic JavaScript instead, recreating the exact risks Hydrogen was supposed to avoid. Custom JS breaks when an event, especially around express checkout, never gets wired up by hand in the first place.
  • The maintenance gap widens over time, not just at the initial build. Shopify updates the Storefront API and Hydrogen together, so a Hydrogen integration tends to keep working as the platform changes. Custom JS has no such guarantee, and nobody sends your dev team a changelog when something it quietly depended on breaks.
  • Neither setup fails with an obvious error. The way to check either one is identical: compare Meta Pixel purchase events against actual Shopify orders for the same window.

Most people talk about headless Shopify like it's all the same, but that's just not true. Tracking on Shopify's Hydrogen framework is a totally different beast than working with a custom Next.js build.

If you don't get the difference between these two, you're going to waste a ton of time. You'll either over-engineer your Hydrogen setup when Shopify already has a fix, or you'll slack on your custom JS build and end up silently losing Meta and CAPI data for months.

Here's the actual difference, and what each one needs.

Is Hydrogen the same kind of headless as a custom JS build?

No. Hydrogen is basically Shopify's own React framework for headless sites. Even though your frontend is totally separate from standard Liquid themes, you're still working within the Shopify ecosystem since it runs on the Storefront API and usually lives on Oxygen.

When you're using a custom JS framework, Shopify is basically just your backend. Since you're working outside the standard Shopify bubble, your dev team has to build every single piece of your tracking setup, from how events trigger to how you collect the data, completely from scratch.

This is exactly what determines how you need to set up your server-side tracking.

What does Hydrogen give you that custom JS doesn't?

HydrogenCustom JS
Framework ownershipShopifyYou (or your dev agency)
Available integration examplesFramework-specific componentsGeneric manual JS only
Event firingSemi-templatedFully manual, every event
Risk of partial coverageLowerHigher
Time to implementFasterDepends entirely on dev bandwidth

Because Shopify runs Hydrogen, you get access to way more pre-built, tested code that plugs right into the framework. It makes setting up server-side tracking a lot easier since developers don't have to waste time reverse-engineering the code just to figure out where to fire purchase events.

Custom JS is a different story. Since there's no official framework to lean on, every setup is unique, and you'll rarely see two Next.js builds that look the same. This means your devs are stuck building, testing, and maintaining every piece of your tracking code from scratch for every single project.

Where does each setup actually break?

On Hydrogen, the biggest issue is when devs try to treat it like a regular site and just slap in generic JavaScript. If they ignore the framework's built-in components and do everything manually, they're basically just creating the same risks you'd have with a custom build, which totally defeats the point of using Hydrogen in the first place.

On Custom JS, things tend to break in sneakier, bigger ways. Since every single event from page views to checking out has to be coded by hand, it's super easy to miss a step. Express checkouts like Shop Pay, Apple Pay, and PayPal are the biggest culprits; because they skip the standard flow, your ad platforms won't see that revenue at all unless your dev explicitly wired up tracking for them. You won't see an error, but your Meta ROAS will look terrible, and you'll end up blaming your ads for a problem that's actually hiding in your code.

Neither of these setups breaks in a way that throws an obvious error. Instead, your Meta ROAS just looks worse than it should, and it's easy to blame the campaign instead of the data feeding it.

How do you tell which one you're actually dealing with?

To figure out if you're on Hydrogen or running a custom JS setup, just peek at your package.json file for the @shopify/hydrogen dependency. If you see it there, you're using Hydrogen and can take advantage of its built-in tracking tools. If you're on something like Next.js, Remix, or Nuxt without that dependency, you're in custom JS territory, which means your team has to build and manage every tracking event from scratch.

You've got to get these architectural differences sorted before you start writing any tracking code. If you try a full manual Conversions API setup on Hydrogen, you're just doing extra work since Shopify already has better ways to handle it. On the flip side, if you assume those same shortcuts work for a custom JS build, you'll end up with huge data gaps that you probably won't even notice until your Q4 numbers look off.

Does anything else break besides tracking?

Yes. Tracking gets the attention because it's where revenue leaks quietly, but it's not the only thing that stops working when you go headless.

Most Shopify apps built as theme app extensions, reviews widgets, upsell popups, loyalty programs, rely on the same theme layer that tracking apps do. Go headless on either Hydrogen or custom JS, and those apps generally stop working the normal way too. If you're auditing tracking, it's worth auditing the rest of your app stack at the same time. Tracking just tends to be the most expensive thing to miss, because the failure is invisible until you check the numbers.

Why does the maintenance gap widen over time?

The difference between Hydrogen and custom JS isn't just how much work the initial build takes. It's who's responsible for keeping it working.

Shopify updates the Storefront API and Hydrogen together. A tracking integration built for Hydrogen today is more likely to keep working as Shopify ships changes, because the framework and the platform move as one unit.

Custom JS has no such guarantee. If Shopify changes something your manual integration quietly depended on, nobody sends a changelog to your dev team. It just breaks, and you find out when the numbers look wrong weeks later.

There's also a hiring problem underneath this. Hydrogen requires specific React and Remix familiarity, at least you know what to hire for. Custom JS could be built on any stack a past developer chose, which means there's no consistent skill profile to hand this off to if that developer leaves.

How do you check if tracking is actually working, regardless of which one you have?

The same way either time: compare your Meta Pixel purchase events to your actual Shopify orders for the same window.

No matter if you're on Hydrogen or a custom build, the way you check if your tracking works is the same. If the numbers match up, you're good. If they don't, you'll know exactly where to look, whether it's a gap in your Hydrogen components or a missed event call in your custom code, but the math you use to spot the problem stays exactly the same either way.

How does Aimerce handle this?

This is exactly where a managed server-side tracking layer saves the day. Aimerce ships Hydrogen-specific integration paths instead of generic examples, and on custom JS builds, handles Conversions API delivery and express checkout capture automatically, across every event, delivered to whichever ad, email, or checkout platform you're actually running, not just Meta. You're not stuck choosing between a fast Hydrogen shortcut and a slow custom build. Either way, someone still has to make sure the data matches what actually happened on the site.

FAQ

Is Hydrogen considered headless commerce? Yes. Hydrogen is Shopify's own headless framework, built on the Storefront API. It's still headless in that there's no Liquid theme, but it stays inside Shopify's ecosystem in a way a fully custom frontend doesn't.

Does Hydrogen support server-side tracking out of the box? No. Hydrogen handles rendering and storefront data. Server-side tracking, Meta Conversions API, Google Ads, Klaviyo, still needs to be explicitly implemented, either by a developer or a tracking layer built for the framework.

How do I know if my Next.js Shopify store is missing tracking events? Compare your Meta Pixel purchase event count against your actual Shopify order count for the same date range. A gap points to missing or misfiring events, most often around express checkout or InitiateCheckout.

Is switching from custom JS to Hydrogen worth it just for tracking? Not on its own. Hydrogen makes tracking implementation faster and lower-risk, but a well-built custom JS integration can be just as reliable. The framework choice should come from broader dev and performance needs, not tracking alone.

What happens if a developer uses generic JavaScript tracking on a Hydrogen site instead of its built-in components? It recreates the same risks a custom JS build has, missed events, partial coverage, manual maintenance, which defeats the point of being on Hydrogen in the first place. The framework's advantage only applies if the built-in components are actually used.

Does the ongoing maintenance burden really differ between Hydrogen and custom JS? Yes, and it widens over time rather than staying fixed at the initial build. Hydrogen updates alongside the Storefront API as one unit, so integrations tend to keep working. Custom JS integrations can break silently when Shopify changes something they depended on, with no changelog pointing to why.

Sources

[1] Shopify, "Hydrogen documentation"

Try Aimerce Pixel Risk-Free
for 30 Days

Most teams see results within 2 weeks.

Money-back guarantee.
It pays for itself, or you don't pay anything.

Install On
Sign Up for a
30-Day Aimerce Pixel Free Trial
Sign Up Using Your Shopify Account Email
*Money back guaranteed.
Aimerce pays for itself or you don’t pay anything.