Connect your website to Reylin

Before you begin

This is documentation for the implemented local build, not evidence of a live hosted service. Use an approved staging installation first. Provider access, sender delivery, browser behavior and deployment persistence still require verification.

Create an account and project, and set the exact website origin, including scheme and port where relevant. The public project ID routes collection requests; it is not a secret or a revenue credential. Your website’s content-security policy must permit the selected analytics host.

1. Load the tracker

Replace both placeholders with your approved host and the project’s public ID. Loading the script alone does not send a pageview.

<script src="https://YOUR-ANALYTICS-HOST/tracker.js"
        data-project="PUBLIC_PROJECT_ID"></script>

2. Connect your consent decision

Call these methods from your consent manager after the script has loaded. Do not grant permission merely because this example contains consent(true). Only send event names you actually need; do not put email addresses, tokens or other sensitive details into event names or campaign values.

• Before consent, track() returns consent_required without sending an event.
• The visitor ID is session-scoped and stored only after consent. Withdrawal removes that stored ID.
• Configure an exact allowed origin; public IDs and browser origin checks are not a complete anti-abuse system.

// After the visitor grants the relevant permission:
reylin.consent(true);
await reylin.track('pageview');

// A deliberate application event:
await reylin.track('signup');

// When permission is withdrawn:
reylin.consent(false);

Optional: consent-aware pageviews for a single-page app

Choose manual pageviews OR this automatic route policy; do not send both for the same visit. Automatic pageviews are off until you configure an explicit mapping. Exact paths and terminal /* prefixes map to nonpersonal static labels; never put customer identifiers in those labels. Query strings and ordinary fragments do not become page labels. Existing categorical utm_source attribution is unchanged.

Configuration may happen before consent, but no navigation hooks, identifier or event are created until consent is granted. Regrant records only the current mapped page, never denied history. GPC=true blocks grants and collection; it is checked on tracker operations/navigation, not through an invented browser change event. Withdrawal stops hooks and aborts pending requests where supported; already delivered events cannot be unsent.

• pushState, replaceState and back/forward are supported; hash routers also observe hashchange. Duplicate notifications/query-only changes do not add automatic events.
• Different concrete paths may map to one static label and still count separate navigation events. Unmapped paths are not sent.
• initial:false skips the current page at each installation/grant; later mapped route changes are collected. No automatic retry or offline replay is added.
• Router methods keep their native return values, arguments and exceptions. Stop restores only tracker-owned wrappers, preserving wrappers installed later by other code. Real framework/browser acceptance is still required.

// Configure once after the script loads; this does NOT grant consent.
reylin.startPageviews({
  mode: 'history', // use 'hash' for #/pricing-style routers
  routes: {'/':'/', '/pricing':'/pricing', '/docs/*':'/docs'},
  initial: true
});
// Later, only after the visitor permits collection:
reylin.consent(true);
// Stop automatic navigation only (does not withdraw consent):
reylin.stopPageviews();
// Withdraw all tracking consent:
reylin.consent(false);

3. Associate a one-time payment on your server

The example below is a server-side shape, not a complete checkout endpoint. Obtain the consented visitor association through your own validated application flow. Keep price selection, credentials and project ownership under server control. Omit the association when it is unavailable; do not invent one.

• Session metadata and PaymentIntent metadata are distinct.
• Do not send Stripe secret or restricted keys to the browser.
• Subscription renewals require a separate persistent customer association; this one-time example does not implement it.

const metadata = consentedVisitorId
  ? { analytics_visitor_id: consentedVisitorId }
  : {};

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: trustedLineItems,
  success_url: trustedSuccessUrl,
  cancel_url: trustedCancelUrl,
  payment_intent_data: { metadata }
});

4. Connect the matching revenue account

This connection measures your customers’ payments; it is separate from paying for this analytics service. In Connections, choose the owned project, matching test-mode account and restricted read key. Account identity is verified before an encrypted draft is stored. The draft supplies a stable webhook endpoint URL but rejects deliveries until activated.

Read access is needed for the account, PaymentIntents and refunds; the optional bounded import also needs Events access. Use the draft URL to configure a webhook endpoint in your own Stripe account for payment_intent.succeeded, refund.created, refund.updated and refund.failed. Then enter that endpoint’s signing secret in the draft’s activation form. The existing account, project, mode and URL stay unchanged; only activation enables deliveries.

Live configuration is deliberately separate and requires explicit server activation, HTTPS and Secure cookies. Test and live connections cannot share a project. A configured connection does not prove that a delivery has succeeded.

5. Verify the whole journey

• With consent granted, send a test event from the allowed origin and inspect the project’s Events view.
• Create a matching test payment. Check source, currency and gross receipts—not the synthetic demo.
• Test a partial refund, repeated delivery and a payment without a visitor association.
• Withdraw consent and confirm no new browser event is sent.
• Check pending-reconciliation warnings and do not call the setup complete until actual provider delivery and browser behavior are verified.

Know the current limits

Monthly event allowances apply across the billing owner’s projects. At cap, new collection pauses without inventing data or automatically charging an overage. Financial reconciliation and existing reports stay available.

The optional last-7/30-day import covers available payment-success events only. It cannot reconstruct visitor history or complete historical refunds; imported reports carry a partial-history warning. Ordered multi-step funnels are implemented. Search Console import and reporting require a separately authorized provider connection; this public preview has no connected providers. Cross-device identity and accounting-system replacement are not available.