Track analytics events

Analytics combines widget activity and package events into site, content, and route-level dashboards.

The goal is not just totals. Creators need timeline filters, content-specific detail views, traffic sources, conversion, and historical comparisons.

Event families

Views, referrers, paths, scroll depth, and time-on-page signals.

Page activity

Impressions, preview clicks, content opens, and route-level engagement.

Content activity

Unlock starts, paid unlocks, failed unlocks, and conversion rate.

Unlock flow

Page activity

The widget tracks views, referrers, path, scroll depth, and time-on-page signals automatically. Events are batched to POST /hub/evt (legacy alias: /hub/track).


window.nibgateHub.track("page_view", {
  path: "/members/post",
  referrer: document.referrer,
  title: document.title
})

Content activity

The widget is event sink; the package is the emitter. The widget exposes a small window API that the SDK calls under the hood:


window.nibgateHub.registerContent(resource)   // (alias: .content) register metadata  → content_registered
window.nibgateHub.track(eventName, payload)   // arbitrary activity → custom/<eventName>
window.nibgateHub.unlockStarted(resource)     // user begins checkout   → unlock_started
window.nibgateHub.unlockCompleted(resource, payment) // successful unlock → unlock_completed
window.nibgateHub.paymentCompleted(resource, payment) // payment settled  → payment_completed

Content on a verified page is detected from data-nibgate-* attributes or nibgate:* meta tags; the package can also send events directly:


import { createGate } from "@nibgate/sdk"
 
const post = createGate({
  id: "post_123",
  title: "Paid research note",
  type: "article",
  price: "2.00",
  path: "/members/post",
  access: {
    humans: "paid",
    agents: "paid"
  }
})
 
post.content()                     // content_registered
post.track("content_impression")   // arbitrary event

The canonical event set

Event	Emitted when	Payload carries
`content_registered`	metadata first published / updated	resource id, title, type, price, path, image, tags
`resource_view`	page with a registered resource rendered	content id, url, route
`unlock_started`	checkout intent begins	content id, price, wallet last seen
`unlock_completed`	server verified the unlock proof	content id, payer wallet, amount, currency
`payment_completed`	payment settled (x402/gateway/transfer)	content id, payer, recipient, txHash, paymentId, provider, network, amount, revenue, currency

Server-side (package/x402) flows emit payment_completed + unlock_completed to the hub automatically from accessResponse() / payAndUnlockResponse() — but only when the creator site sets NIBGATE_SITE_ID, NIBGATE_SITE_TOKEN, and NIBGATE_API_BASE. Without those, payments still process and return proofs; only hub counts/Explore volume stay static.

Unlock flow

A normal unlock funnel should produce enough data to answer:

How many people viewed the content?
How many clicked unlock?
How many paid successfully?
Which source sent the highest-converting traffic?
Which content earned the most over time?

Dashboard metrics

The creator dashboard should show timeline filters, traffic sources, top content, unlock conversion, receipt drilldowns, and earnings trends.