Your board asks for the renewal rate. You pull last quarter’s membership numbers and the figure looks great. Then someone notices that a family who moved from Individual to Family in month four is counted as a “renewal,” and so is a patron who dropped from Patron to Dual halfway through their term. Neither of those people renewed anything. They changed level while they were still members.
Mixing these together inflates retention, hides downgrade trends, and makes it hard to tell whether your renewal mailings are working. The fix is mostly a reporting discipline: decide what each transaction means, then build queries that sort them before anyone calculates a rate.
Why the numbers blur together
Altru keeps a transaction history on each membership, and each transaction carries some kind of action (join, renew, rejoin, upgrade, downgrade, and similar). In theory, that is enough to separate them. In practice, three things get in the way:
- Staff pick the action. At the desk or in the back office, a level change near expiration is sometimes entered as a renewal at the new level, and a mid-term change is sometimes entered as a renewal because it was the familiar option. The action field is only as clean as the habits behind it.
- Upgrades and renewals can happen in one step. A member who renews early and moves up a level is legitimately both. Your reports need a rule for which bucket that lands in.
- Standard reports answer a different question. Out-of-the-box membership reports tend to summarize activity by level and date range. They are not necessarily built to answer “of the people who were due to expire, how many came back, and separately, how many changed level mid-term?” If you are unsure what a given Altru report counts, run it for a narrow date range against a handful of members you know, and compare.
Define the buckets before you query anything
Agree on definitions with whoever owns membership goals. A workable set:
- Renewal: a payment that extends the term, made within your renewal window around the expiration date (for example, from 90 days before to your grace period after). Same level or different level, it counts once as a renewal.
- Renewal with level change: a subset of renewals where the new level differs from the old one. Report it as a line under renewals, not as a separate count, so nobody adds it twice.
- Mid-term upgrade: a move to a higher level made outside the renewal window, while the member still has meaningful time left.
- Mid-term downgrade: the same, to a lower level. These are rare, but they are an early warning about price sensitivity, so track them even if the count is small.
- Rejoin: a returning member after the grace period. Keep this out of the renewal rate, or report it as its own line.
The key move is that “renewal” is defined by timing relative to expiration, not only by what someone selected on the transaction. That protects your rate from data entry habits.
Building the query
Start from a membership transaction query rather than a membership or constituent query, so each row is one event. Useful output fields:
- Transaction date and the action recorded on it
- Membership level before and after (or the level on the transaction plus the prior level, depending on what your query view exposes)
- The expiration date that was in effect before the transaction, and the new expiration date
- Amount and the membership program
- Constituent lookup ID, so you can spot-check individuals
Field names and availability vary by view, so browse the membership and membership transaction areas of the query designer to see what your database exposes. If the prior expiration date is hard to get directly, a second query of memberships with their expiration history can be joined by membership in a spreadsheet.
Then classify each row with a simple calculation: days between the transaction date and the previous expiration date. Inside your renewal window means renewal; outside it, with a level change, means mid-term upgrade or downgrade, depending on level rank. A small lookup table that ranks your levels (Individual = 1, Dual = 2, Family = 3, and so on) makes the up versus down decision automatic.
Check the action field against the timing
Once you have both, add one more column: does the recorded action agree with the timing-based bucket? Rows where they disagree are your training list. If you see many “renewals” happening seven months before expiration, that is a desk process issue, not a membership trend.
Reporting it to leadership
Keep the summary short and separated:
- Renewal rate = renewals in the period divided by memberships that were due to expire in the period. Note how many of those renewals included a level change.
- Mid-term movement = upgrades and downgrades as raw counts, with net revenue change.
- Rejoins on their own line.
Use the same window and grace period every time. Changing definitions between quarters makes trend lines meaningless, so write the definitions at the bottom of the report.
Keeping it from becoming a monthly spreadsheet chore
The classification step usually lives in a spreadsheet, which means someone exports the query, pastes it in, and refreshes formulas each month. Data Bridge can sync an Altru query to Google Sheets, so the transaction data lands in the same sheet where your bucket formulas and level ranking already live. Altru stays the source of the data; the sheet just does the sorting.
Quick answers
Should an early renewal with an upgrade count as a renewal or an upgrade?
Count it once, as a renewal, and flag the level change underneath. Counting it in both places is the most common way renewal rates get overstated.
Can I trust the action recorded on the transaction?
Use it, but verify it against timing. The comparison column will tell you quickly whether your data entry is consistent enough to rely on.
