The first-time donor who never comes back: what to fix before spending on acquisition

Why is the second gift the number that matters?

Because the first one rarely pays for itself.

Acquiring a donor costs something: an ad, a campaign, an event, staff hours. A single gift from a new supporter often does not cover that cost, and the organisation only comes out ahead if the person gives again. So the second gift is not a nice outcome on top of the first. It is the point at which acquisition stops being an expense.

Which makes the reporting question uncomfortable. If you cannot say what happened to last year's new donors, you cannot say whether last year's acquisition worked. You can only say how much it produced on the day.

We are deliberately not quoting a donor retention rate here. Reliable figures for this come from one place, the Fundraising Effectiveness Project, and we could not retrieve its report on the day we wrote this. Everything else in circulation is a summary of a summary. The argument does not need a number: whatever your retention is, you cannot manage it without measuring it, and most organisations are not.

Can Google Analytics answer it?

No, and the reason is structural rather than a reporting oversight.

Three things about GA4 make it the wrong instrument for a retention question, and all three are documented by Google.

User-level data expires, and on a free property the ceiling is 14 months. The retention control offers exactly two options for user-level data on a standard property: two months or 14. Longer windows are a paid tier. Google adds, verbatim, "This retention period also applies to key events data." A question about whether last year's donor gave again this year is a question about a person over more than a year, and that data is gone.

A returning user is a returning browser. GA4 identifies people through what it calls identity spaces, and the accurate one has to be built: "User-ID is the most accurate identity space, because it uses data you collect to identify your users." Using it means you "consistently assign IDs to your users and include the IDs along with the data you send to Analytics." That is development work. Without it, on websites "the device ID gets its value from the client ID," which means a phone and a laptop are two people, and a cleared cookie is a new one.

And a growing property is quietly downgraded. Verbatim: "When a standard property becomes Large or a 360 property becomes XL, the event-level data retention setting is automatically reduced to 2 months and event-level data older than 2 months becomes inaccessible and is permanently deleted." Warning emails go to property administrators, which in a small nonprofit is frequently a contractor who left two years ago.

There is a fourth detail that makes the problem sharper rather than softer. GA4 offers a setting called Reset on new activity, which refreshes a person's identifier every time they come back, so an active user never reaches the expiry date. Google spells out the other half: if the user "doesn't initiate a new session before the retention period expires, then that user's data is deleted." The people whose data survives are the ones who keep visiting. The people who disappear are the ones the retention question is about, and they are precisely the ones the system deletes first.

There is one softening detail. Retention limits apply to explorations and funnels, not to standard aggregated reports: "the data retention setting does not affect standard aggregated reports." Trend lines survive. The person-level analysis does not. So a chart of new donors by month will still be there in three years. The list of who they were will not.

So where does the retention number live?

In the donor database, and nowhere else.

This is the part worth being blunt about. Analytics tells you how people arrived. The CRM tells you who they are and what they did next. Retention is a question about people over years, so it belongs to the system that keeps people over years.

The practical implication is that the retention project is a database project, not an analytics project. If the CRM does not record how a donor first arrived, no dashboard will reconstruct it later.

What has to be true in the database first?

Four fields, and most organisations are missing at least two.

A first-gift date on every record. Not a created date, which is when someone typed the record in. The date of the first gift.

A source on the first gift. Event, appeal, grant, website, walk-in. One field, one controlled list, filled in every time. A free-text field with forty spellings of "website" is the same as no field.

A consistent identity. Two records for the same person split their giving history in half and make retention look worse than it is. Deduplicating before measuring is not a tidy-up, it is a prerequisite.

A gift type that separates recurring from one-off. A monthly donor and an annual donor have completely different retention behaviour and averaging them produces a number that describes nobody.

None of that requires new software. It requires the fields you already have to be filled in the same way every time, which is an operations problem rather than a marketing one.

How do you connect the website to it without a data project?

UTM tags on everything you send out, and one honest limitation to plan around.

Google's rule on the parameters is short: "When you add parameters to a URL, you should always use utm_source, utm_medium, and utm_campaign." That is enough for a small organisation. Every email appeal, every social post, every QR code on a flyer gets the same three, spelled the same way every time. The longer version of that discipline is in UTM tags explained for small business owners.

One documented trap will otherwise waste an afternoon. Campaign tags do not appear where most people look for them: "UTM parameters are omitted in the following dimensions: Landing page + query string, Page path + query string," and are instead carried in the Page location dimension. Building a landing-page report and finding no campaign data does not mean the tags failed.

The bridge to the CRM is simpler than it sounds: carry the same campaign name into the donation form, so the gift record and the analytics report use one vocabulary. If the appeal is called spring_appeal in the URL, it is called spring_appeal on the gift.

What should the monthly report show?

Fewer numbers than most nonprofit dashboards, and different ones.

Three lines are enough to start. New donors this month. Second gifts from donors whose first gift was in a defined earlier period. And the source split on both. That is a report a board can read in a minute and act on, which is more than can be said for a page of traffic charts. The general argument for choosing few numbers deliberately is in the numbers a small business owner should actually see.

Two things not to put on it. Sessions, unless something specific hangs on them. And any comparison against a sector benchmark, because you do not have a sourced one and a made-up one will get repeated in a grant application.

Before any of it, write down where you are now. A retention figure with nothing to compare it to tells you nothing next quarter, and that is the whole case in setting a baseline before you change anything.

What would we do first?

The order matters more than the tooling.

Run the query you are afraid of. Take the donors whose first gift was in a completed period at least a year back, and count how many gave again. Even a rough answer changes the conversation, and it takes an afternoon in any CRM worth the name.

Fix the four fields going forward. First-gift date, source, deduplication, gift type. Do not attempt to backfill five years of history; start clean from a date and accept that the older data is what it is.

Tag the outbound links. Three UTM parameters, one spelling convention, written down where the next person can find it.

Then look at acquisition. More traffic against a leaking second gift produces a bigger leak. If the organisation is also running a Google Ad Grant, its monthly conversion requirement is a useful forcing function here, since a homepage visit is explicitly not allowed to count. The rules are in Google Ad Grants for Bay Area nonprofits, and the discovery side is in how donors find a small Bay Area nonprofit.

Where these numbers come from

Three Google Analytics help pages, each read in full on 7 September 2026.

The retention limits, the note that they cover key events data, the exemption for aggregated reports and the automatic reduction for Large properties are from data retention. The identity spaces, the accuracy of User-ID and the device-ID behaviour on websites are from reporting identity. The three required parameters and the dimensions that omit them are from collecting campaign data with custom URLs.

We have deliberately not published a donor retention rate, a first-time donor retention rate, or a sector benchmark. The Fundraising Effectiveness Project is the primary source for those figures and we could not retrieve its report on the day we wrote this. When we can read it, we will cite it and not before.