Analytics

Every part of the platform throws off behavioural exhaust. A reader runs a search, an assistant serves a passage, a customer buys a book or lets a subscription lapse. Analytics is where those signals accumulate — the platform's behavioural memory. It is deliberately not a reporting bolt-on that watches from the outside: what lands in the analytics lake flows back into the platform (search ranking boosts, trending labels) and forward into operational uses (marketing audiences, royalty pool inputs).

One positioning rule shapes everything on this page: analytics never rides the public API. It is an internal stream with governed consumers. Integrators see its outcomes — better-ranked results, a trending label, eventually a royalty statement — never the raw telemetry.

Three families of signal

Three kinds of behaviour matter to the platform, and each arrives by a different door.

Search telemetry is the family that exists today. Every executed search against the Content Lake emits a search.executed record, and readers' relevance feedback joins it — both stream through a delivery pipeline into the analytics lake, where they sit as queryable tables rather than log files. This is the raw material for everything in the "flowing back" section below.

Consumption is the AI-era signal. Whenever an AI surface serves content — a first-party assistant, a licensed partner — one platform.usage.content.v1.served event is published per served response. Each item in the event carries the resource and version that was served, the Work it belongs to, and plain facts about the serve: its rank in the response, whether it was served, whether it was cited. The rights basis under which the serve was allowed is pinned at serve time, so later contract changes never rewrite history. The plain-English version of this story lives on AI usage under How AI use is tracked.

Commerce is the oldest signal of all: orders, subscriptions, and refunds on Packt's own storefronts. Those transactions create entitlements and feed royalties in their own right; to analytics they are the demand-side complement to consumption — proof that attention converted. Catalogue and promotion context from Product Management tells analytics which storefront presentation the customer actually saw.

Facts in, judgements out

The consumption stream records what happened, never what it is worth. A usage event says "this resource was served at rank three and cited" — it never says "this serve is worth 0.4 of a pool share".

That separation is deliberate. Rates and bases live in the contract model on Royalties; the weights that divide a pool are a versioned policy owned by the future Royalty service, applied at settlement. Because the observed facts are immutable and the valuation is applied later, Packt can refine how a pool is attributed without ever re-observing behaviour — the memory stays honest while the judgement evolves.

What flows back into the platform

Analytics would be inert if it only accumulated. The first consumers of the lake are the platform's own services.

flowchart LR
    S["Search telemetry"] --> LAKE["Analytics lake"]
    U["Usage events"] --> LAKE
    O["Orders & subscriptions"] --> LAKE
    LAKE -->|Analytics Refresh| PERF["Per-Resource performance<br/>fields in search"]
    LAKE -->|system labels| TREND["Platform-maintained labels<br/>e.g. trending"]
    LAKE -.->|in design| AUD["Audiences<br/>(Marketing)"]
    LAKE -.->|in design| POOL["Pool inputs<br/>(Royalty operations)"]

An Analytics Refresh workflow periodically aggregates the lake into per-Resource performance metrics — measures like thirty-day sales — and patches them onto the corresponding rows in the search estate. Ranking can then blend textual relevance with proven performance: a title that demonstrably converts earns a boost no editor had to configure.

The same aggregates drive system labels. Labels like trending are platform-maintained rather than human-applied — analytics decides when a Resource has earned one and when it has cooled off, and the label machinery described in Access and labels applies the change. Nobody curates trendiness by hand.

What flows forward

Two consumers sit downstream of the lake rather than inside the platform loop, and both are in design.

• Audiences. Marketing wants segments built from behaviour — readers who searched for a topic, consumed adjacent content, but never bought. Analytics is where such audiences would be computed; how they are surfaced to campaign tooling is an open question.
• Royalty pool inputs. Subscription-style and AI surfaces settle from consumption pools, and dividing a pool fairly requires exactly the served/cited facts the usage stream preserves. The future Royalty service described on Royalties will consume usage aggregates as its attribution input; analytics keeps the books it will read.

Never on the public API

There is no /analytics endpoint, and none is planned. Telemetry rides internal buses and internal pipelines; the lake's consumers are registered platform services and governed internal tooling, each reading under its own scopes. The events integrators can consume are the platform's platform signals, documented on Events — deliberately thin notifications, not telemetry.

If future work does claim analytics-owned events, they will follow the platform grammar (platform.<service>.<entity>.v<major>.<verb>). The sketches below are illustrative, not yet claimed:

For the vocabulary used on this page — Resource, Work, entitlement, system label — see the glossary.

Related pages

• Search — where search telemetry originates and where performance metrics are patched back.
• Royalties — the royalty model today, and the future Royalty service that will consume usage aggregates.
• AI usage — how AI use is tracked, in plain English.
• Events — the platform event signals integrators can consume, as distinct from internal telemetry.
• Content Lake — the content estate whose behaviour analytics remembers.