To connect GA4 and CRM donation data reliably, use a privacy-safe identifier or transaction key that appears in both systems, preserve the scope of every traffic-source field, and assign a confidence level to each match. Do not treat a similar timestamp, gift amount, or campaign name as proof that two records belong together. And do not send names, email addresses, phone numbers, or other personally identifiable information to Google Analytics.
The goal is not a report in which every gift has a source. The goal is a report that distinguishes confirmed connections from plausible ones, preserves genuinely unknown gifts, and gives fundraisers enough evidence to make a responsible campaign decision.
Why GA4 and CRM donation totals do not match automatically
GA4 measures website and app activity. A fundraising CRM records gifts, donors, designations, adjustments, and relationship history. Those systems observe different parts of the donor journey, so their totals should not be expected to agree without a declared joining method.
The difference is especially important in Google Analytics 4 because traffic-source dimensions have different scopes. First user source describes where a person was first acquired, session source describes the source that began a particular session, and event-scoped source dimensions are used for attribution around key events. Google documents these scopes separately and warns that values from reports with different scopes should not be compared as though they mean the same thing. Review Google’s traffic-source scope guidance.
A CRM gift may also arrive without a usable digital path. The donor may give through a third-party form, return later on another device, mail a check after seeing an appeal, use a donor-advised fund, or block analytics collection. “Unmatched” is therefore a legitimate reporting result, not a data-cleaning failure that must be forced into a channel.
Start with a shared, privacy-safe data contract
A data contract is a short agreement about which fields are created, where they travel, what they mean, and who owns them. For GA4-to-CRM donation attribution, the first version should be deliberately small.
| Field | Where it originates | Why it matters |
|---|---|---|
| Non-PII transaction or handoff key | Donation flow | Creates the strongest record-level connection when stored in both the analytics event and gift record |
| Event timestamp | GA4 or event export | Shows when the measured donation action occurred |
| Gift timestamp and amount | CRM or donation platform | Provides the financial system-of-record outcome |
| UTM source, medium, campaign, and content | Campaign link | Preserves the declared marketing source that brought the visitor to the site |
| GA4 source scope | Reporting definition | Prevents first-user, session, and event attribution from being mixed |
| CRM appeal, campaign, fund, or designation | Fundraising system | Preserves the operational and accounting context of the gift |
| Match method and confidence | Reporting layer | Makes the evidence behind each connection visible |
Google Analytics supports custom campaign parameters such as utm_source, utm_medium, utm_campaign, and utm_content. Google also explains that a session is associated with one campaign or traffic source and that campaign values collected mid-session do not rewrite the session source. That is why a fundraiser should preserve the original fields rather than flatten everything into one generic “source” column. See how GA4 collects and processes campaign sources.
The privacy boundary is non-negotiable
Google’s policy prohibits sending personally identifiable information such as email addresses, phone numbers, and full names to Google Analytics. The prohibition also applies to accidental exposure in URLs, page titles, campaign parameters, and custom dimensions. Follow Google’s PII prevention guidance.
If your organization uses GA4 User-ID, the identifier must not contain information a third party could use to identify the person. Google also recommends using the built-in User-ID feature rather than registering a user ID as a custom dimension. User-ID can improve continuity across sessions, but it does not replace consent, privacy review, access controls, or a clear retention policy. Review the official User-ID requirements.
Use a four-level donation attribution evidence ladder
Once the fields are available, assign every CRM gift to exactly one evidence level. The label describes the strength of the connection between the gift and the analytics record. It does not claim that the campaign caused the donation.
Level 1: Confirmed transaction match
The same privacy-safe transaction or handoff key appears in the analytics event and the CRM gift. The timestamp and amount also pass the organization’s validation rules. This is the strongest technical match.
Decision use: campaign performance, donation-path diagnostics, and record-level quality review.
Level 2: Confirmed pseudonymous user match
A compliant, non-identifying User-ID or another approved first-party key connects the website journey to the CRM record, and the gift falls inside the declared time window. The person connection is strong, but the campaign-credit rule still depends on source scope and timing.
Decision use: donor journey analysis, assisted-source reporting, and cross-session behavior.
Level 3: Inferred campaign match
No shared record key exists. A campaign code, landing path, gift time, source values, and amount create a plausible connection under a documented rule. This level should remain aggregated when individual identity is uncertain.
Decision use: directional campaign learning, never donor-level stewardship or definitive source claims.
Level 4: Unmatched or conflicting
The gift has no eligible analytics record, multiple plausible records, a missing key, a broken handoff, an out-of-window visit, or conflicting campaign evidence. Keep it visible as unmatched or send it to a review queue.
Decision use: measurement coverage, exception diagnosis, and implementation priorities.
A worked example: 1,000 CRM gifts
Suppose a nonprofit records 1,000 eligible gifts during a campaign period. After applying the evidence ladder, the reporting layer produces this result:
| Evidence level | Gifts | Share of gifts | How to report it |
|---|---|---|---|
| Confirmed transaction | 620 | 62% | Confirmed digital connection |
| Confirmed pseudonymous user | 140 | 14% | Confirmed donor journey; credit depends on declared scope and window |
| Inferred campaign | 90 | 9% | Directional, aggregated campaign evidence |
| Unmatched or conflicting | 150 | 15% | Unknown; do not distribute across channels |
These numbers are illustrative, not a sector benchmark. The useful result is not an 85% “attribution rate” created by combining every nonblank row. The report should show at least three separate metrics:
- Confirmed match rate: (620 + 140) ÷ 1,000 = 76%
- Inferred match rate: 90 ÷ 1,000 = 9%
- Unmatched rate: 150 ÷ 1,000 = 15%
Revenue coverage should be reported separately because a few large offline or donor-advised fund gifts can make gift-count coverage and dollar coverage tell very different stories.
Build the report in seven practical steps
- Choose the decision. Decide whether the report will evaluate acquisition, a single appeal, donation-form performance, or assisted campaign influence. One join cannot answer every attribution question.
- Name the system of record. Use the CRM or approved financial source for posted gift outcomes. Use GA4 for measured website behavior and campaign context.
- Define eligible records. Document how tests, refunds, reversals, pledges, recurring installments, anonymous gifts, soft credits, and offline gifts are handled.
- Preserve source scope. Store first-user, session, and event attribution in separate fields. Never overwrite them into one ambiguous source value.
- Apply the evidence ladder. Use the strongest valid rule first, then move downward. Stop when a record qualifies; do not count it in multiple levels.
- Calculate coverage and exceptions. Report confirmed gift coverage, confirmed revenue coverage, inferred coverage, unmatched coverage, duplicate-key count, and conflicting-source count.
- Release with a confidence statement. State the as-of date, source scope, lookback window, exclusions, and share of results that remain inferred or unmatched.
For teams that need event-level analysis, Google identifies BigQuery Export as the supported path for exporting raw GA4 events and combining them with external data. It is also the feature Google points to for joining Analytics data with first-party CRM data for offline-event analysis. Read the GA4 BigQuery Export overview and Google’s User-ID analysis guidance.
Do not make these five attribution mistakes
- Joining on email inside GA4. Email is PII and must not be passed to Google Analytics.
- Matching only on amount and time. Repeated gift amounts and busy campaign periods create false positives.
- Mixing source scopes. First-user acquisition, session acquisition, and event attribution answer different questions.
- Redistributing unknown gifts. Allocating unmatched revenue proportionally across known channels hides the size and pattern of the measurement gap.
- Treating a match as causation. A technical connection shows that records belong to the same journey; it does not prove the campaign caused the gift.
Use a release rule before campaign results drive decisions
A practical GA4 and CRM donation attribution report should be marked ready, qualified, or blocked for its named decision.
- Ready: shared keys are unique, the source scope is declared, material exclusions are documented, and confirmed coverage meets the organization’s decision threshold.
- Qualified: the report is usable for directional learning, but inferred or unmatched gifts could change a channel-level conclusion.
- Blocked: PII is exposed, keys collide, source scope is unknown, or the unmatched pattern is concentrated enough to reverse the recommendation.
The thresholds should be set by your organization and recorded in a reporting rules registry. Attribution windows should also be explicit; the ReportWerks attribution window report guide explains how to separate recent, plausible influence from stale source credit.
Where ReportWerks fits
ReportWerks brings marketing, fundraising, and performance data into one reporting system. For a GA4 and CRM workflow, that means keeping website behavior, campaign fields, gift outcomes, match confidence, and reporting rules close enough that a leader can see both the result and the evidence behind it.
The strongest dashboard is not the one that attributes every dollar. It is the one that shows which connections are confirmed, which are inferred, which remain unknown, and what the team should fix before the next campaign decision.
GA4 and CRM donation attribution checklist
- Use a shared non-PII transaction or user key where possible.
- Keep PII out of GA4 URLs, events, campaign parameters, and identifiers.
- Preserve first-user, session, and event source fields separately.
- Define eligible gift types and exclusions before joining records.
- Assign one evidence level to every gift.
- Report confirmed, inferred, and unmatched coverage separately.
- Compare gift-count coverage with revenue coverage.
- Publish the source scope, attribution window, as-of date, and limitations.
- Block decisions when privacy, key uniqueness, or material coverage checks fail.
