How to Use Product Usage Data Before a Customer Renewal Meeting

A practical pre-renewal usage-review workflow

A useful renewal-preparation workflow has eight parts:

1. Verify the data. Confirm account identity, users, automation, eligibility, taxonomy, time range, and known gaps.
2. Choose a relevant period. Match the comparison to the customer’s lifecycle and real product cadence.
3. Build an account overview. Summarize meaningful activity, active users, product areas, concentration, and major changes.
4. Inspect product-area adoption. Identify recurring, newly adopted, declining, dropped, and intentionally irrelevant workflows.
5. Review users and role coverage. Find workflow owners, champions, backup candidates, new users, declining users, and role gaps.
6. Interpret changes in context. Compare the account with its own history first, then use defensible peer context where useful.
7. Review selected Visits and known outcomes. Use session evidence to investigate specific questions, not to characterize the whole account from one recording.
8. Prepare a one-page briefing. Separate facts, interpretations, questions, possible actions, and data limitations.

The purpose is not to produce a longer analytics report. It is to help the product, customer-success, and account teams enter the renewal meeting with specific evidence and better questions.

What product usage can—and cannot—tell you

Behavioral product data is useful because it records what people did inside the product. It can help a team identify patterns that are difficult to reconstruct from memory or anecdotal updates.

Product usage can contribute evidence about:

• workflows that recur;
• product areas and grouped pages that are used;
• active users and their apparent product roles;
• account breadth across relevant workflows;
• meaningful outputs created in the product;
• current behavior compared with previous periods;
• declining or growing participation;
• concentration around a primary champion;
• possible backup users;
• visible workflow friction worth investigating;
• possible gaps between eligible and adopted capabilities;
• product areas, accounts, or roles that may need support.

This evidence is especially useful in B2B SaaS because a customer account often contains several users, roles, teams, and workspaces. A global user average can hide whether one person performs nearly all meaningful work or whether adoption is distributed across the account. For a broader method, see how to analyze product usage by company.

Product data normally cannot establish the following on its own:

A renewal briefing should therefore distinguish what was observed from what still needs to be learned.

Choose a review period that matches the customer’s cadence

There is no universal renewal-review period.

The right period depends on:

• the renewal cycle;
• the product’s expected usage cadence;
• the customer lifecycle;
• seasonality;
• implementation milestones;
• release timing;
• the customer’s own workflows;
• whether the account recently changed teams, workspaces, or product configuration.

Possible comparisons include:

• the most recent 30 days versus the immediately preceding 30 days;
• the most recent 90 days versus the immediately preceding 90 days;
• the current completed quarter versus the previous completed quarter;
• the current cycle versus the same cycle last year;
• a stable post-onboarding period versus the onboarding period;
• time since a major rollout versus the equivalent period before the rollout;
• current use versus a relevant lifecycle-, plan-, eligibility-, and size-matched peer group.

Use completed, equal-length periods whenever possible. If one period contains 31 days and another contains 20, raw counts are not directly comparable without normalization.

Expected cadence matters more than an arbitrary default. A payroll workflow may be monthly. A governance review may be quarterly. Annual planning may create a temporary spike. An administrative capability may be used only when teams or permissions change. Judging any of those workflows from seven days of activity can create a false concern.

Before choosing a window, ask:

• How often is this workflow supposed to occur?
• Did onboarding or a rollout change the account’s expected behavior?
• Was either period affected by holidays or seasonality?
• Did a product release change the event definition or navigation path?
• Is the account old enough to support a year-over-year comparison?
• Is the comparison period representative, or was it itself unusual?

Historical context from the account is usually the strongest starting point because it reflects that customer’s product configuration and working rhythm.

Check data quality before interpreting behavior

A polished briefing built on incorrect identity or taxonomy is worse than no briefing.

Renewal data-quality checklist

Verify the following before drawing conclusions:

• Account identity: Confirm that the company record represents the intended customer.
• User-to-company assignment: Check that users are associated with the correct account and reporting period.
• Internal and support exclusions: Remove or label employee, implementation, support, testing, and solution-engineering activity.
• Automation and integration activity: Separate human behavior from service accounts, scheduled jobs, APIs, and integrations.
• Product-area grouping: Confirm that grouped pages and product areas still represent the customer’s actual workflows.
• Feature eligibility: Do not classify an unavailable capability as an adoption gap.
• Account lifecycle: Distinguish onboarding, rollout, steady-state use, migration, and offboarding.
• Complete time range: Check late-arriving data, partial days, missing dates, and incomplete current periods.
• Instrumentation changes: Identify event renames, duplicate events, SDK changes, route changes, and newly instrumented workflows.
• Known data gaps: Make missing events or uncertain identity visible in the briefing.
• Timezone: Use the correct account or reporting timezone when comparing days, weeks, and months.
• Multiple workspaces: Determine whether the customer’s activity is split across production, sandbox, regional, or departmental workspaces.

Do not hide a limitation because the chart looks polished. A short statement such as “Administration completion was re-instrumented midway through the quarter, so the trend is directional” is more useful than a precise-looking but invalid comparison.

Build a concise account-level overview

The account overview should help the team understand the shape of usage before opening individual pages or sessions.

Include:

No single metric should dominate the preparation.

A customer health score can be one useful summary signal, but it should lead to supporting evidence rather than replace it. Likewise, a lower active-user count may be important, irrelevant, or even expected depending on the workflow.

Review product-area adoption

Next, move from the account summary into the product structure.

For each relevant product area or grouped workflow, inspect:

• whether the account is eligible to use it;
• whether use represents meaningful adoption rather than discovery;
• whether use recurs at the expected cadence;
• how broadly it is used across the account;
• which users and roles participate;
• how use changed from the comparison period;
• whether critical workflow steps are completed;
• whether visible gaps or incomplete paths need investigation;
• whether an adjacent, automated, or alternative workflow replaced it.

Useful questions include:

• Which areas are embedded in the customer’s process?
• Which areas were previously used but recently disappeared?
• Which areas are intentionally irrelevant to this customer?
• Which areas are used by one specialist because that ownership model is appropriate?
• Which workflows produce outputs for colleagues who do not use the product directly?
• Did a release, migration, or integration change the observed path?
• Is low usage a problem, or is the capability designed for occasional administration?

A workflow can create value for non-users. For example, one analyst may create a report that is distributed to ten stakeholders outside the product. Product data can show the report creation and perhaps in-product review, but the broader audience and decision impact may require customer confirmation.

Review users and role coverage

User count alone is insufficient.

A customer may have many occasional viewers but no active workflow owner. Conversely, one specialist user may be entirely appropriate for an administrator-owned capability.

Inspect:

• the primary champion;
• likely workflow owners;
• active users;
• new users;
• users with declining participation;
• dropped users;
• users gaining momentum;
• possible backup candidates;
• relevant role coverage;
• permissions that may block participation;
• user concentration;
• participation by team, workspace, or department.

Ask what each user appears to contribute:

• Does the person create, configure, review, approve, administer, or merely view?
• Is the apparent role consistent over time?
• Does another user understand the critical workflow?
• Did a previously active person leave, change responsibilities, or move to another workspace?
• Is a new user beginning to take ownership?
• Is narrow ownership expected, or is it an operational dependency?

For deeper methods, see how to identify champion concentration risk and how to find backup product champions.

Avoid ranking individual employees unnecessarily. The goal is to understand role coverage and continuity, not to create a performance scorecard for the customer’s staff.

Review meaningful trends and changes

Trend analysis should focus on behavior that matters to the customer’s workflow.

Useful changes include:

• meaningful activity;
• active-day consistency;
• product-area breadth;
• active-user count;
• user penetration;
• top-user concentration;
• time to first meaningful use;
• recurring-use frequency;
• movement relative to relevant peers;
• unusual spikes, gaps, or step changes.

Use the correct type of change:

• Use percentage change for counts.
• Use percentage-point change for rates or shares.

For a count:

If meaningful workflows fall from 164 to 151:

For a share, describe the direct difference. If the top user’s share rises from 49% to 72%, the increase is 23 percentage points.

Be careful with tiny baselines. An increase from one completed workflow to three is a 200% increase, but the absolute change is only two workflows. Show both the underlying count and the relative change.

Also ask whether the metric’s meaning changed. A fall in manual exports after an integration launch may represent successful workflow substitution rather than declining value. A spike in Administration may reflect a one-time migration rather than sustainable adoption.

Separate facts, interpretations, and questions

This is the central discipline of an evidence-based renewal briefing.

A fact is a supported observation.

An interpretation is a possible meaning of that observation.

A question is how the team tests the interpretation with the customer.

Example 1

Fact

Five users completed Reporting workflows in the current quarter, down from eight in the previous quarter.

Interpretation

Reporting participation has narrowed.

Question

Did the Reporting team or workflow change during the quarter?

Example 2

Fact

The top user produced 82% of meaningful activity.

Interpretation

Usage is highly concentrated.

Question

Is this expected specialist ownership, or should another user be able to continue the workflow?

The fact does not automatically prove the interpretation. Reporting participation may have narrowed because two employees moved teams, a workflow became automated, or the customer completed a seasonal project. Concentration may represent a fragile dependency, or it may reflect a deliberate specialist role.

Writing the three lines separately prevents assumptions from being presented as customer truth. It also improves the quality of the meeting: the team brings a specific observation and asks the customer to explain its context.

Use historical and peer context carefully

Use context in this order:

1. The account’s own previous behavior
2. The account’s expected workflow cadence
3. Lifecycle-matched peers
4. Plan- and eligibility-matched peers
5. Account-size and role context
6. A broader benchmark only when its population and methodology are defensible

The account’s history is often more relevant than a global average. A customer with a quarterly governance workflow should not be compared casually with accounts that use the same product area every day.

When using peers, document:

• the cohort definition;
• the number and type of accounts included;
• the comparison period;
• feature eligibility;
• lifecycle stage;
• account size;
• whether automation is handled consistently;
• whether the measured workflow is expected to have the same cadence.

Do not tell a customer that it is “below average” without explaining what the comparison means and why it is relevant. A peer median is context, not a mandatory target.

For a fuller treatment, see how to build peer baselines for B2B SaaS.

Review selected Visits only when they answer a specific question

Aggregate data tells you that a pattern exists. A Visit can help explain what happened in a particular session.

Reviewing individual Visits may be useful when you need to investigate:

• repeated incomplete setup;
• failed workflows;
• unusual return patterns;
• behavior after a major product change;
• an unexplained decline in completion;
• a successful versus unsuccessful path;
• a support issue connected to a known workflow.

The internal team should:

1. Define the question before opening replay.
2. Review only the necessary sample.
3. Protect sensitive information.
4. Distinguish observation from interpretation.
5. Compare successful and unsuccessful examples where useful.
6. Validate prevalence with aggregate data.
7. Avoid presenting one session as representative of the whole account.
8. Avoid sharing replay details casually in the customer meeting.

For example, three selected Visits may show users repeatedly returning to an Administration page before leaving setup incomplete. That is evidence about those three sessions. It does not establish that every user is confused or that the interface caused the behavior. Check the aggregate completion pattern, instrumentation, eligibility, permissions, and support context before forming a broader hypothesis.

Do not show a raw replay to the customer by default. Use one only when there is a clear and appropriate reason, the customer context is understood, privacy requirements are met, and the replay is the best way to discuss a specific issue.

See how to review session replays without overinterpreting them.

Connect usage to known customer outcomes

Usage becomes more useful when it is connected to a customer’s stated goals.

Possible outcome areas include:

• reports delivered;
• workflows completed;
• projects managed;
• errors reduced;
• time saved;
• collaboration enabled;
• governance improved.

Do not infer the outcome merely because an event occurred.

Use already documented customer outcomes where available. If an outcome is not observable, prepare a question:

• “How are the Reporting outputs used after they leave the product?”
• “Did the integration change the time or effort required for this process?”
• “Which decisions depend on the monthly dashboard review?”
• “What result would make this workflow successful for the next term?”

Customer-stated outcomes should take precedence over a convenient proxy selected by the internal team.

Document risk and expansion ideas as hypotheses

Risk and expansion ideas should be recorded separately from established facts.

Examples include:

• participation may be narrowing;
• Reporting may depend on one user;
• an adjacent integration may address repeated manual exports;
• low usage may reflect an expected quarterly cadence;
• a dropped product area may have been replaced by automation;
• unresolved workflow friction may be limiting adoption.

Every hypothesis should include:

Example:

Use at-risk account analysis for portfolio triage and product-usage expansion analysis for a deeper treatment of expansion evidence. Neither should be reduced to a purchase or churn verdict.

One-page pre-renewal briefing template

Keep the briefing concise enough to guide a meeting. Supporting charts and detailed user evidence can remain available for follow-up.

Account context

• Lifecycle stage
• Renewal timing
• Known customer goals
• Plan and relevant feature eligibility
• Implementation or rollout history
• Important organizational changes
• Workspaces or teams included in the analysis

Usage summary

• Selected current period
• Comparison period
• Meaningful activity or workflows
• Active human users
• Relevant product areas
• Overall trend
• User penetration
• Top-user concentration
• Important peer or historical context

Established value evidence

• Recurring workflows
• Meaningful outputs
• Participating roles
• Adopted product areas
• Workflows that remain stable
• Customer-confirmed outcomes already on record

Changes worth discussing

• Declining or growing participation
• Dropped or newly adopted areas
• New, declining, or dropped users
• Concentration changes
• Workflow friction worth investigating
• Automation or integration changes
• Unexpected gaps or spikes

Questions for the customer

• Are the previously stated outcomes still relevant?
• Did the team, ownership model, or workflow change?
• Are important users or roles missing from the data?
• Are low-use areas intentionally irrelevant?
• Which current product outputs matter most?
• What priorities will shape the next term?

Possible next actions

• Product support
• Targeted training
• Workflow improvement
• Backup ownership
• Permission or setup correction
• Relevant expansion investigation
• Product feedback
• No action

“No action” is a valid conclusion when the observed pattern is expected and the customer confirms that the workflow is working as intended.

Data limitations

• Missing or recently changed events
• Identity uncertainty
• Automated activity
• Incomplete periods
• Seasonality
• Multiple workspaces
• Feature-eligibility uncertainty
• Peer-group limitations
• Outcomes not observable in product data

Worked B2B renewal example: Northstar Works

Northstar Works is approaching renewal after its first year. The renewal meeting is six weeks away. Reporting and Dashboard workflows remain recurring, Collaboration use has fallen, active human users declined from nine to six, and one analyst now creates most outputs. A manager still reviews dashboards every month. An integration was enabled during the current quarter, after which manual exports declined. Several incomplete setup Visits appeared in Administration. One new user is gaining momentum. Peer comparisons are mixed, and the product data contains no direct evidence about satisfaction, budget, procurement, or renewal intent.

Illustrative account summary

Illustrative example — fictional Northstar Works data

1. Verify the data

The team checks the account before interpreting it:

• Northstar Works has one production workspace and one sandbox workspace. Sandbox activity is excluded.
• An internal support user and a solution engineer are excluded from customer user counts.
• Integration service-account activity is labeled separately from human activity.
• Northstar is eligible for Reporting, Dashboard, Collaboration, Administration, and Integrations.
• The Administration completion event changed after a product release. Current-quarter setup starts and completions can be inspected, but the previous-quarter trend is not directly comparable.
• The reporting timezone matches the customer’s agreed operating timezone.
• The selected quarter is complete.
• User-to-company assignments are checked for the six active human users.
• The integration’s automated activity is retained as workflow context but not counted as human engagement.

This review prevents the service account from inflating active-user or event totals and prevents the sandbox from making account adoption look broader than production use.

2. Select relevant periods

Because Northstar is finishing its first annual term, a year-over-year comparison is not available.

The team selects:

• the most recent completed quarter;
• the immediately preceding completed quarter of equal length;
• monthly detail within the current quarter for workflows expected to recur monthly;
• post-integration detail for manual exports and automated activity.

The team does not use only the most recent seven days because Reporting and management review have monthly cadence.

3. Summarize account usage

The account-level summary is not simply “usage declined.”

A more accurate summary is:

Meaningful human workflows declined 7.9% and active human users declined from nine to six. Reporting output remained stable to slightly higher, and a manager continued monthly Dashboard review. Reporting participation and overall activity became more concentrated. Collaboration participation fell substantially. Manual exports declined after an integration was enabled. Administration contains several incomplete setup attempts, although a prior-period trend is unavailable because instrumentation changed.

This summary makes the mixed pattern visible.

4. Identify established value evidence

The team records behavior that appears established:

• Reporting produced 45 outputs in the current quarter, compared with 42 previously.
• Reporting occurred in every month of the quarter.
• A manager reviewed Dashboard content in every month.
• The integration ran repeatedly after enablement.
• Manual exports fell from 38 to nine after the integration became active.
• A new analyst’s meaningful activity increased from one workflow in the first month to five in the second and nine in the third.

The team does not translate those observations into invented outcomes. It does not say that Reporting saved time, that the integration reduced errors, or that dashboards improved decisions. Those are questions for Northstar.

5. Identify changes worth discussing

Four changes deserve attention:

1. Active human users declined from nine to six.
2. Reporting output ownership became more concentrated.
3. Collaboration contributors fell from six to two.
4. Six of 14 Administration setup starts did not reach the currently defined completion state.

The manager’s monthly Dashboard review and the new analyst’s growing activity are important counterevidence against a one-dimensional account narrative.

6. Separate facts from hypotheses

Reporting concentration

Fact

Three users created Reporting outputs this quarter, down from five, while the lead analyst created 31 of 45 reports.

Interpretation

Reporting participation has narrowed and output ownership is more concentrated.

Alternative explanation

Northstar may have intentionally centralized Reporting under one specialist, with adequate offline backup.

Question

“Is this the intended Reporting ownership model, and who can continue the workflow when the lead analyst is unavailable?”

Confidence

Medium.

Next validation step

Confirm roles and determine whether another user should complete at least one recurring Reporting workflow.

Collaboration decline

Fact

Collaboration contributors fell from six to two, and meaningful Collaboration actions fell from 31 to 12.

Interpretation

Collaboration is less embedded in the current workflow.

Alternative explanation

The team may have moved collaboration to another system or completed a project that temporarily required more in-product participation.

Question

“Is Collaboration still part of the process you want to support, or did the team move that work elsewhere?”

Confidence

Low to medium.

Next validation step

Confirm workflow relevance before proposing training, product changes, or expansion.

Integration and exports

Fact

Manual exports fell from 38 to nine after the integration became active.

Interpretation

The integration may have replaced part of the manual export workflow.

Alternative explanation

Export demand may have declined independently.

Question

“How did the export process change after the integration was introduced, and what result did that change create for the team?”

Confidence

Medium.

Next validation step

Document the customer’s process and identify an outcome they consider meaningful.

Administration setup

Fact

Six of 14 Administration setup starts did not reach the currently instrumented completion state.

Interpretation

Some setup attempts may be encountering friction.

Alternative explanation

Users may be reviewing configuration without intending to finish, permissions may prevent completion, or the event definition may miss a valid path.

Question

“Have administrators had difficulty completing this setup, or are they using a different process?”

Confidence

Low to medium.

Next validation step

Compare selected incomplete Visits with a successful Visit, confirm event coverage, and review any related support context.

7. Select a small, justified Visit sample

The team does not open dozens of recordings.

It reviews:

• three Administration Visits that ended after repeated setup steps without the completion event;
• one successful Administration Visit for comparison;
• one Reporting Visit from the lead analyst;
• one Reporting Visit from the new analyst.

The replay review is internal and question-led.

The team notes:

• what was visibly observed;
• what remains uncertain;
• whether the selected sessions resemble the aggregate pattern;
• whether permissions, loading states, navigation, or instrumentation need further review;
• whether sensitive information appears and should be masked or excluded.

The team does not tell the customer, “We watched your recordings and saw that your team was confused.” It converts the review into a neutral question about the setup process.

8. Prepare customer questions

The briefing contains a small number of priority questions:

1. Which Northstar outcomes currently depend on Reporting and Dashboard?
2. Did team membership or role ownership change during the quarter?
3. Is the lead analyst intended to own most Reporting output?
4. Who can continue the workflow if that analyst is unavailable?
5. Is Collaboration still relevant, or did the process move elsewhere?
6. How did the integration change the manual export process?
7. Have administrators had difficulty completing setup?
8. What workflows and stakeholders will matter most in the next term?
9. Are budget, procurement, security, or organizational issues affecting the renewal process?

The last question is essential because no product metric can answer it.

9. Draft the meeting agenda

For Northstar, the team proposes:

1. Reconfirm the goals established during onboarding and any organizational changes.
2. Review the recurring Reporting and Dashboard workflows.
3. Ask how Northstar uses the outputs and what results they support.
4. Discuss narrower Reporting participation and confirm the intended ownership model.
5. Ask whether Collaboration is still relevant.
6. Review the integration’s role and the change in manual exports.
7. Discuss Administration setup only at the level needed to understand the process.
8. Confirm stakeholders, next-term priorities, actions, owners, and measurements.

The analytics dashboard supports the agenda. It is not the agenda.

10. Define follow-up measurements

The team prepares possible measurements but confirms them with Northstar before treating them as goals:

• whether a second user completes a recurring Reporting workflow;
• the number of active Reporting contributors;
• whether Administration setup completes after support or product changes;
• whether Collaboration remains an agreed workflow;
• the balance of manual and automated exports;
• the new analyst’s role and recurring participation;
• the customer-defined outcome associated with Reporting or the integration;
• the next review period and expected cadence for each workflow.

Illustrative Northstar Works one-page briefing

The correct conclusion is not:

“Usage declined, so Northstar is at risk.”

The evidence supports a more precise preparation:

Northstar retains recurring Reporting and Dashboard behavior, and an integration may have replaced manual work. At the same time, active-user breadth, Collaboration participation, and Reporting ownership have narrowed, while several Administration setup attempts warrant investigation. The renewal conversation should validate outcomes, ownership, workflow changes, setup needs, commercial context, and next-term priorities.

That conclusion is more useful because it preserves both established evidence and uncertainty.

A practical renewal-meeting agenda

A product-usage review should serve the customer conversation rather than take it over.

1. Reconfirm goals and changes since the previous review.
2. Review the customer’s important workflows.
3. Validate the outcomes they receive.
4. Discuss observed changes with neutral questions.
5. Review blockers or missing capabilities.
6. Confirm stakeholders and workflow owners.
7. Discuss relevant next priorities.
8. Agree on follow-up actions and measurements.

Keep detailed charts available, but do not walk through every metric. Select the evidence that helps the customer explain its process and make decisions.

Language to use and avoid

Use language that is observable, neutral, and open to correction.

Neutral wording is not merely polite. It protects the quality of the analysis by inviting information that can confirm or disprove the team’s assumptions.

What to do after the meeting

The meeting should change the account record.

Afterward:

• update organizational and workflow context;
• confirm, revise, or reject each hypothesis;
• document customer-stated outcomes;
• correct user-role assumptions;
• correct feature-eligibility assumptions;
• record changes in workspaces, teams, or integrations;
• define actions, owners, and due dates in the system that manages customer work;
• choose the next relevant measurement period;
• monitor only the workflows the customer agreed were important;
• share validated product issues with the product team;
• record data-quality problems for instrumentation work;
• stop using signals the customer or subsequent evidence has invalidated.

For example, if the illustrative Northstar Works account confirms that Collaboration is intentionally handled elsewhere, repeated low Collaboration use should not continue to appear as an unexplained concern in every account review.

Protect privacy and customer trust

Detailed behavioral evidence requires restraint.

The internal team should:

• limit access to individual-level behavior;
• use aggregate account evidence where possible;
• minimize sensitive information;
• avoid exposing individual employee rankings unnecessarily;
• review only the Visits needed for the question;
• follow applicable retention and access rules;
• configure masking, exclusion, and capture rules;
• avoid collecting data that is not needed;
• distinguish replay observation from interpretation;
• avoid surprising the customer with invasive detail;
• present product data transparently and respectfully.

Session replay can reveal more context than an aggregate chart. That makes it useful for a narrowly defined investigation and risky as casual meeting material.

A respectful renewal conversation might say:

“We found several incomplete Administration attempts and want to understand whether setup has been difficult.”

It should not begin with a detailed account of an individual employee’s clicks, pauses, or mistakes.

Privacy controls are technical safeguards, not a substitute for legal, security, and compliance review.

Common mistakes in pre-renewal usage analysis

How Hymetry connects account summaries to user and Visit evidence

Hymetry is account-centric product intelligence for B2B SaaS. It organizes product evidence around accounts rather than leaving teams to reconstruct the customer from disconnected event and replay views.

A practical investigation path is:

Company overview → Product-area changes → User and role distribution → Relevant Visits → Customer questions

In Companies, a team can start with the account’s current and previous periods, product-area use, active users, company attributes, and visible changes.

From there:

1. Use Pages to inspect the relevant product areas and grouped pages.
2. Use Users to understand who contributes to the account pattern, how participation is distributed, and whether activity depends on one person.
3. Use Visits to review selected session evidence when an aggregate pattern creates a specific question.
4. Return to the briefing with supported observations, careful interpretations, and customer questions.

Company attributes can help teams compare accounts by plan, lifecycle, size, region, owner, integration status, or another relevant category—provided the comparison is defensible.

Hymetry helps organize the evidence. It does not replace:

• direct customer conversations;
• customer-stated outcomes;
• commercial and procurement context;
• support history;
• account planning;
• renewal workflow systems;
• human judgment.

For more customer-success applications, see Hymetry for customer success.

Frequently asked questions

Which product-usage metrics belong in a renewal briefing?

Include only metrics that help explain the account’s important workflows: active human users, meaningful workflows or outputs, product-area adoption, user penetration, recurring-use cadence, user concentration, and material changes from a relevant comparison period. Add data limitations and known customer outcomes. Do not include a metric merely because it is available.

How far back should I review product usage before a renewal?

Use a period that matches the customer’s lifecycle and expected workflow cadence. Thirty days may suit a frequently used operational product, while a completed quarter or year-over-year seasonal comparison may be more relevant elsewhere. Avoid using an incomplete current period or a seven-day window for monthly and quarterly workflows.

Does declining product usage mean a customer will churn?

No. Declining usage is an observation that may justify investigation. It can reflect organizational change, automation, seasonality, completed work, reduced need, missing instrumentation, friction, or declining value. Product behavior does not establish renewal intent by itself.

Does growing usage prove an expansion opportunity?

No. Growth can support an expansion hypothesis, but purchase intent also depends on customer outcomes, unmet needs, stakeholder support, eligibility, budget, authority, procurement, and timing. Validate those factors with the customer.

Is one power user always a concentration risk?

No. Some workflows are appropriately owned by one administrator or specialist. Concentration becomes a useful question when the workflow is critical, continuity matters, and no backup ownership is understood. Ask whether the ownership model is intentional.

Should I show a session replay during the renewal meeting?

Not by default. Review selected Visits internally when they help answer a specific question. Use aggregate, neutral language in the meeting. Show a replay only when there is a clear purpose, appropriate consent and context, privacy safeguards, and a reason it is better than a concise description.

How should I use peer benchmarks?

Prefer the account’s own history first. When using peers, match lifecycle, plan, feature eligibility, account size, and expected cadence. Explain the cohort and treat the median as context, not a mandatory target.

How do I connect usage to customer value?

Begin with the customer’s documented goals. Identify observable workflows and outputs that may relate to those goals, then ask the customer to validate the result. Do not convert report creation, workflow completion, or engaged time directly into an invented claim about time saved, revenue, satisfaction, or business impact.

What should happen when the customer disproves a usage hypothesis?

Update the account context, mark the hypothesis as rejected, and stop using the invalidated signal in the same way. Correct role, eligibility, workflow, automation, or cadence assumptions so future reviews do not repeat the mistake.

Sources

These sources inform the renewal-preparation, account-analysis, questioning, measurement, data-quality, and privacy practices in this guide. Product usage remains one evidence layer alongside customer, commercial, support, and organizational context.

1. GitLab Handbook — “Commercial Renewal Process.” https://handbook.gitlab.com/handbook/customer-success/comm-sales/renewals/
2. GitLab Handbook — “Customer Success Plan.” https://handbook.gitlab.com/handbook/solutions-architects/processes/customer-success-plan/
3. Gainsight — “How to Run an Executive Business Review That Drives Impact.” https://www.gainsight.com/blog/executive-business-review/
4. Nielsen Norman Group — “Attitudinal vs. Behavioral Research in UX.” https://www.nngroup.com/articles/attitudinal-behavioral/
5. Program on Negotiation at Harvard Law School — “The Ladder of Inference: A Resource List.” https://www.pon.harvard.edu/daily/negotiation-skills-daily/the-ladder-of-inference-a-resource-list/
6. Harvard Business Review — “The Surprising Power of Questions.” https://hbr.org/2018/05/the-surprising-power-of-questions
7. Mixpanel Documentation — “Group Analytics: Group users together as an aggregated unit of measurement.” https://docs.mixpanel.com/docs/data-structure/group-analytics
8. Twilio Segment Documentation — “Spec: Group.” https://www.twilio.com/docs/segment/connections/spec/group
9. Twilio Segment Documentation — “Data Collection Best Practices.” https://www.twilio.com/docs/segment/protocols/tracking-plan/best-practices
10. Google Analytics Developers — “Reporting Data Expectations.” https://developers.google.com/analytics/devguides/reporting/data/v1/reporting-data-expectations
11. Mixpanel Documentation — “Insights: Visualize trends and compositions within your data.” https://docs.mixpanel.com/docs/reports/insights
12. UK Office for National Statistics — “Percentages and percentage points.” https://service-manual.ons.gov.uk/content/numbers/percentages
13. EUR-Lex — “Regulation (EU) 2016/679 (General Data Protection Regulation).” https://eur-lex.europa.eu/eli/reg/2016/679/oj
14. United States Federal Trade Commission — “Privacy and Security.” https://www.ftc.gov/business-guidance/privacy-security
15. Commission Nationale de l’Informatique et des Libertés — “Draft recommendation concerning session replay tools.” This is a closed public-consultation draft and non-binding guidance, not final law, regulation, or a final CNIL recommendation. https://www.cnil.fr/sites/default/files/2026-02/recommendation_draft_session_replay.pdf