A loaded script is not a completed integration. Verify browser collection, server usage, account identity and payment evidence as separate steps; none requires adding GA4.
Keep public and server credentials separate
The browser snippet uses the site key supplied by your own GOD installation screen. A server write-only ingest key belongs only in the server environment. Do not copy the Grow or Die marketing site's key, put an ingest key into client JavaScript, or paste credentials into logs. Use an explicitly designated test site for synthetic checks.
Load the browser snippet once, with the site's correct allowed origin. A 403 collection response needs an origin/key investigation, not a blanket allow-all setting. Inspect the collection request's status without copying authorization headers into tickets.
Reuse one server telemetry instance
import { GrowOrDie } from "@grow-or-die/sdk";
const ingestKey = process.env.GROW_OR_DIE_KEY;
if (!ingestKey) throw new Error("Missing server ingest key");
const telemetry = new GrowOrDie({ ingestKey });
// Only after your application has verified these identities:
await telemetry.identify({
accountId: "account_example",
userId: "user_example",
visitorId: "visitor_example",
identifiers: { stripe: "cus_example" },
});Those IDs are placeholders, not records to send to production. Wrap the model client using the provider-specific OpenAI streaming recipe or Anthropic cache recipe. Attach the real opaque account context around your application's existing call. Do not manufacture a billed model call just to make a dashboard non-empty.
The acceptance checklist
- Browser: one genuine page visit reaches the intended test site; duplicate scripts do not double count.
- Server: the wrapper preserves the provider response and stream behavior.
- Usage: the final provider-reported token categories and model identity are observed; missing usage remains unknown.
- Identity: a verified account links to the intended visitor and payer; conflicting links are rejected or surfaced.
- Revenue: a verified payment source supplies the fact; an SDK event is not proof of a payment.
- Privacy: prompts, generated answers, emails and credentials are absent from analytics metadata.
- Shutdown: flush bounded telemetry at the appropriate lifecycle boundary; delivery failures are observable without hiding the application's own result.
What should appear first?
A browser visit can appear before model cost or revenue. A server cost can appear without a visitor link. This is expected partial evidence, not a reason to invent joins. First verify each input, then the relationship between them. GA4 and PostHog may enrich acquisition, but GOD's browser and server SDK are the native collection path.
Estimate the expected economics with the margin calculator while waiting for real evidence. Keep test traffic separate from production growth reports.
What this evidence can and cannot prove
The checklist verifies individual collection boundaries, not a complete customer lifecycle, causal acquisition or audited profit. A green health endpoint alone does not prove an SDK event was accepted and linked correctly.