QBR data checklist: 5 checks for an account evidence pack

• Define the analysis level: Verify that your activity counts use a customized group identifier, such as a company ID, rather than individual user IDs, to match the account review scope.
• Distinguish export scopes: Separate incremental changed-item exports from large search exports, noting that Zendesk documents different request allowances for each.
• Inspect usage timing: Account for asynchronous updates in usage summaries, as recently submitted meter events may not immediately appear in reported totals.
• Interpret subscription states: Recognize that a subscription can belong to multiple states, and that queried and returned base states may differ, according to Recurly documentation.
• Verify grouping limits: Confirm that your project supports the required group types, as PostHog allows up to 5 group types in one project for company, team, or project behavior analysis.

These checks ensure your QBR evidence pack reflects the underlying records accurately before presenting account activity and billing information.

Verify the identifier used for activity counts before presenting account data. Group Analytics in Mixpanel allows behavioral data analysis at a customized group level, such as account, device, or any other way you want to assess your business, according to Mixpanel. This capability supports uniquely counting events by an alternative identifier, such as company ID, invite ID, or another value shared by a group of individuals with different distinct_ids, according to Mixpanel. Confirm that your tracking setup uses this alternative identifier rather than relying solely on individual distinct_ids.

Ensure the grouping matches the account review scope. Group analytics in PostHog is useful when you need to track behavior at the company, team, or project level, according to PostHog. Check that the specific group type configured in your project aligns with the account structure you intend to review. You can create up to 5 group types in one project, according to PostHog. Verify that the account-level group type is among those defined in your project configuration.

Review the available group type capacity to ensure the account grouping fits within the project limits. If the account identifier is not set as an alternative identifier for event counting, the activity counts may not reflect company-level behavior accurately, according to Mixpanel.

Confirm that the group level used for analysis matches the scope of the QBR. The group definition must be intentional and aligned with the account review objectives. Check that the group type used for the account review is explicitly defined and not conflated with individual user tracking, according to PostHog.

Ensure the identifier used for counting is consistent across the data sources you plan to include in the evidence pack. If the account is identified by a company ID, verify that this ID is used as the alternative identifier for event counting, according to Mixpanel. The group analytics feature supports tracking behavior at the company, team, or project level, so the chosen group type must correspond to the account structure, according to PostHog.

Related guide: Customer data sync: 4 steps for account activity feeds.

When pulling support data for a QBR, you must distinguish between incremental exports and large search exports, as each serves a different purpose and has distinct technical limits. The choice between these two methods determines how you retrieve ticket history and how you manage API request quotas during data collection.

For routine updates where you need to capture new or modified tickets since a previous pull, use the incremental export API. This endpoint is designed specifically to get items that changed or were created in Zendesk Support since the last request, according to Zendesk. This approach is efficient for tracking ongoing account activity without re-downloading the entire history. If you need to verify the structure of the data before running a full collection, you can run a sample export for a specific resource, which returns only up to 50 results in one request, according to Zendesk. This small sample allows you to test the response format without consuming significant bandwidth or time.

When configuring the incremental export, be aware of the page size limit. The parameter that specifies the number of results to be returned per page allows up to a maximum of 1,000, according to Zendesk. Additionally, you must respect the rate limits for these endpoints, as you can make up to 10 requests in one minute, according to Zendesk. Planning your export schedule around 10 requests in one minute prevents API errors during the collection phase.

If your QBR requires a comprehensive search that will return more than 1,000 results, the incremental export is not the appropriate tool. Instead, use the search endpoint, which is documented for search queries that will return more than 1,000 results, according to Zendesk. The rate limit for this specific endpoint is higher than the incremental export; it is rate-limited to 100 requests in one minute for one account, according to Zendesk.

To apply these limits to your QBR preparation: 1. Determine if your data need is for recent changes or a full historical search. 2. If recent changes, use the incremental export API and set the page size to no more than 1,000. 3. Schedule incremental pulls to stay within 10 requests in one minute. 4. If a full search is needed and will exceed 1,000 results, switch to the search endpoint. 5. Ensure your search script accounts for 100 requests in one minute for one account.

By matching the export method to the scope of your query and respecting the specific rate limits for each endpoint, you ensure a reliable and complete data collection process for your account evidence pack.

Once you have pulled the raw records, verify how the billing and subscription systems handle timing and state before you present the figures. Start with the usage data from your billing provider. To record usage, first configure your meter, and then send meter events that include the event name configured on the meter, customer ID, numerical value, and a timestamp (optional), according to Stripe. Check that your event payloads contain these specific fields.

Timing is a critical variable in these checks. Stripe processes meter events asynchronously, so aggregated usage in meter event summaries and on upcoming invoices might not immediately reflect recently received meter events, according to Stripe. If you pull a summary right after a large batch of events is sent, the numbers may appear lower than the actual activity. Note the time of your data pull and the time of the last event sent. If the account has high-volume usage, allow a buffer period between the last event and the QBR presentation to ensure the summaries have processed.

Prevent double-counting during the review. Use idempotency keys to prevent reporting usage for each event more than one time because of latency or other issues, according to Stripe. If your integration retries failed requests, verify that the idempotency keys are consistent. Inconsistent keys can cause the same usage event to be recorded twice, inflating the account’s consumption figures.

Related guide: Customer usage discrepancies: 4 steps before renewal.

Next, examine the subscription records. The List Subscriptions endpoint returns a list of all the subscriptions, according to Recurly. When you query this list, be aware of how states are handled. Please note: a queried state and the base state of a returned subscription may differ, according to Recurly. Compare the state you requested with the state shown on each returned record.

State membership can also be non-exclusive. A subscription may belong to more than one state, according to Recurly. This means a single subscription record might appear in multiple state categories simultaneously. If your QBR deck segments accounts by subscription status, ensure your logic accounts for this overlap. Do not assume that a subscription in one state is excluded from another.

To apply these checks, pull the subscription list for the account and cross-reference the state fields. If a subscription shows a state that differs from your query filter, note the discrepancy. If a subscription appears in multiple state groups, adjust your segment definitions to reflect the overlap. These steps ensure the billing and subscription data in your QBR pack accurately reflects the account’s current standing.

Related guide: Check portal rules on 4 billing tools before sharing.

Verify that your QBR evidence pack includes records from each of these five source types.

Five checks on one account: a company identifier for 10 people, a 50-row sample, a page of 1,000, 100 usage events, then a wait, and 2 subscription states noted together.

For one upcoming QBR, write down the group identifier, the export method, the last usage event time, and the state on each returned subscription.

What belongs in a QBR data checklist?

A QBR data checklist should include five source-specific checks: support exports, company activity, account grouping, metered usage, and subscription records. These checks verify that the underlying records match the account review scope before you present activity and billing information. Reviewing these specific areas helps ensure your evidence pack reflects the actual data available in your source systems.

How can Mixpanel count activity by company rather than individual user?

Mixpanel counts by an alternative identifier such as company ID. Using these alternative identifiers ensures your activity counts reflect the company rather than individual user actions.

Does the five group type limit apply to my PostHog project?

Yes. PostHog allows creating up to 5 group types in one project, according to PostHog. This limit applies to the specific project where you are configuring your group analytics. Verify your current group type usage to ensure you have sufficient capacity for your account review structure.

When might Stripe usage summaries omit recently received meter events?

Recently received meter events might not appear in summaries immediately. This timing difference means your QBR data may show a lag between event submission and summary updates. Check the timestamp of your meter events to account for this processing delay.

Can a Recurly subscription belong to more than one state?

Yes. A subscription may belong to more than one state. This overlapping state membership means a single subscription record can reflect multiple concurrent conditions. When reviewing subscription lists, account for this possibility to accurately interpret the account's billing status.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.