What your Pendo click data tells you and how to use the Aggregation API.

Click events are Pendo's most granular data, and the easiest to misread. Every tagged feature produces a stream of events with a visitor, an account, and a timestamp attached, but a raw count on its own tells you very little. The value comes from how you slice it.

Sliced by feature, click data shows you which parts of the product carry real usage and which are ignored. Sliced by visitor and account, it separates one power user hammering a button from genuine adoption across a customer. Sliced over time, it shows whether a release, a guide, or an onboarding change actually moved behaviour, not just whether totals went up.

Three things distort raw click counts in almost every Pendo account. Internal users, your own team testing and demoing, can be a third of all events if they aren't segmented out. Power users concentrate volume: a handful of visitors often produce most of a feature's clicks, so a rising total can mean deeper usage by the same few people, not wider adoption. And repeat interactions inflate everything: a user who clicks an export button thirty times in one session is one unit of adoption, not thirty.

The fix is to stop reporting totals and start reporting ratios: unique visitors per feature, the share of accounts that used a feature at least once, and how usage persists week over week. Those are exactly the kinds of questions the Aggregation API answers well.

Pendo's built-in dashboards and CSV exports cover the common questions, but they are snapshots: someone has to run the export, and the answer is stale the moment it lands in a spreadsheet. For recurring reporting, like a weekly adoption review, a client-facing usage report, or a wallboard, you want the data to come to you.

The Aggregation API gives you query access to the same event data that powers Pendo's own UI. You authenticate with an integration key and send a pipeline: a sequence of stages, similar to a database query, where each stage shapes the output of the previous one: select a source, filter it, group it, sort it.

POST https://app.eu.pendo.io/api/v1/aggregation
x-pendo-integration-key: <your-integration-key>

{ "response": { "mimeType": "application/json" },
  "request": {
    "name": "clicks-by-feature-last-30-days",
    "pipeline": [
      { "source": {
          "featureEvents": null,
          "timeSeries": {
            "period": "dayRange",
            "first": "date_add(now(), -30, \"days\")",
            "count": 30 }}},
      { "group": {
          "group": ["featureId"],
          "fields": { "clicks": { "sum": "numEvents" } }}},
      { "sort": ["-clicks"] }]}}

Reading it top to bottom: the source stage pulls feature click events day by day for the last 30 days, the group stage sums clicks per feature, and the sort stage ranks them. Swap the group key to visitorId or accountId and the same query answers a completely different question. From there the response is plain JSON. Feed it to any charting library and the report updates itself.

The pipeline above is the easy part. Getting it into production is the rest: the integration key has read access to your entire subscription, so it has to be stored and rotated like any other secret and never shipped to the browser. Large accounts page their responses, so a naive query silently truncates. And a feature ID on its own means nothing until you join it to the visitor and account metadata that says who these people actually are.

Then it has to keep running: a scheduled refresh, somewhere to host it, a chart layer, and an alert for when a pipeline quietly starts returning zero because a tag broke upstream. None of it is especially hard, but it is the difference between a query you ran once and a report a team can trust every week. That part is what I build.

Once the pipeline is in place, these are the reports I build most often for clients. None of them are available as a single number in the standard dashboards:

• Adoption rate: share of active accounts that used a feature at least once in the period. It's the honest version of 'is anyone using this?'
• Stickiness: daily active users over monthly active users, per feature. It separates habits from one-off visits.
• Time to first use: days from signup to first click on a key feature. This is the metric that tells you whether onboarding actually works.
• Feature share: each feature's percentage of total engagement. It shows where your product's gravity really is.

The dashboard below is a working example of what this kind of reporting looks like when built directly on the Pendo Aggregation API. It pulls click events by feature, visitor, and account with a daily trend line, feature share breakdown, and a full event log. If you want this built for your product, connected to your live Pendo data, that's a service I offer.