Bundle size is a product decision, not just an engineering one. The AIOProductOS product-analytics SDK is a single script — productos.js, about 3.7 KB gzipped — that loads asynchronously and lands every event on a shared spine. It is one of seven drop-in SDKs that each gzip to between 1.7 and 5.2 KB, so instrumenting your product costs kilobytes, not a Core Web Vitals regression. You install it in your own product; events flow to the spine and join to the same customer’s revenue and shipped work.
Why does SDK bundle size matter?
Because the analytics script runs on your customer’s device, on every page, before you learn anything. A heavy analytics bundle is the most common self-inflicted Core Web Vitals wound: it competes with your own JavaScript for the main thread and delays interactivity.
The math is unforgiving. A typical third-party analytics tag can run 20–50 KB gzipped or more; some tag-manager-loaded stacks push past 100 KB before a single event fires. At 3.7 KB, productos.js is roughly an order of magnitude smaller, and it loads with async so it stays off the critical rendering path — it does not block your Largest Contentful Paint or first render.
The web performance targets most teams hold — LCP under 2.5s, a landing-page JS budget under 150 KB gzipped — leave very little room for a bloated analytics tag. A few kilobytes is a rounding error against that budget. Fifty is not.
What do you actually get in the SDK?
A tracking primitive and sensible autocapture, not a framework you have to learn. You drop a script tag and call a track function:
<script async src="https://platform.aioproductos.com/sdk/productos.js"
data-org="your-org-key"></script>
<script>
// illustrative — call shape, not a documented API contract
productos.track("feature_used", { feature: "export", plan: "team" });
</script>That is the whole integration surface for the analytics piece. The SDK captures page and event data, buffers it, and flushes without blocking navigation. It runs on both EU and US data residency, chosen at onboarding — the region never appears in your key or your markup.
The other six SDKs follow the same pattern. Session replay records what a user actually did, in-app chat opens a conversation surface, plus scheduling, product guides, surveys, and a shared core. Add only what you need; each is a few kilobytes.
How do events join to revenue and work?
This is the part a standalone analytics tool cannot do. When an event lands, it lands on the spine keyed to the same customer and account IDs your billing and work records already use. So the event is not stranded in an analytics silo — it resolves to one record next to that customer’s subscription, support history, and the features your team shipped.
That collapses questions that are normally a manual join:
| Question | Standalone analytics | Analytics on a spine |
|---|---|---|
| Which accounts used a feature? | Event export | One query |
| Do paying accounts use it more than trials? | Join events to Stripe by hand | Already joined |
| Did the feature we shipped move retention? | Cross-reference 3 tools | On one record |
The value is not the pixel; it is that nothing downstream has to reconcile it. See how the mapping works on the analytics page and the full SDK family on the SDKs page.
When is a full CDP the better call?
When instrumentation is not the bottleneck — distribution is. If you need to fan events out to twenty downstream destinations, enforce a governed tracking plan across many squads, run dedicated identity resolution, or load a warehouse as the system of record, a customer-data platform like Segment is the right tool. That is infrastructure, and it is a real discipline with a team behind it.
A lightweight SDK is the opposite bet: instrument fast, keep the bundle tiny, and land events somewhere already joined to revenue and work so a small team can answer product questions without a data pipeline. If your problem is “we have no instrumentation and no data team,” the few-kilobyte script wins. If your problem is “we have fifteen tools that all need the same event,” you want the CDP. Some teams run both — the SDK to capture, the CDP to distribute.
The short version
A product-analytics SDK should cost you kilobytes and give you answers. productos.js is ~3.7 KB gzipped, loads async, and lands events on a spine where a click joins to a subscription and a shipped feature on the same customer record. You do not get a bigger dashboard — you get instrumentation that is already connected.
You can see connected events on one record without installing anything — browse the live no-signup demo and follow a customer from a tracked event to their subscription to the feature that shipped for them.