Give every fundraising link one source key

Give each fundraising-link placement one stable source key, then keep its campaign, destination, and channel in separate fields. Test the finished donor path before launch. Call the result gift-level attribution only when that key survives into the completed gift or transaction record; otherwise, label it as click or session evidence.

That boundary matters when one appeal appears in an email, a printed program, a lobby sign, and a board member's message. Sending every placement to the same donation page is tidy for donors. Reusing one unmarked link leaves your team unable to tell the placements apart.

Build one four-part link record

For nonprofit donation tracking links, start with a small register. Each row needs four facts:

1. Source key: the stable name for one placement, such as `august-email-footer` or `gala-program-qr`.
2. Campaign: the appeal or initiative the placement supports, such as `fall-scholarships`.
3. Destination: the final hosted page or page containing the embedded form.
4. Medium: the route the donor used, such as email, print, partner, or organic social.

This separates questions that teams often collapse into one label. The campaign answers, “Which fundraising effort?” The source key answers, “Which exact placement?” The destination answers, “Where did the donor land?”

Google Analytics defines `utm_source`, `utm_medium`, `utm_campaign`, and `utm_content` as distinct campaign parameters. It also treats parameter values as case-sensitive, so `GalaProgram` and `gala-program` can split into separate report rows. Pick lowercase values and keep them stable after launch.

Do not put a donor's name, email, expected amount, or other personal detail in a source key. URLs get copied, logged, and shared. A placement label should identify the link, not the person using it.

Create a new key when the placement changes

Two links can support the same campaign and lead to the same page while needing different source keys. A QR code in the event program and a QR code on the registration desk are different placements. If one works and the other does not, your team can change the right asset next time.

Use a new source key when at least one of these changes:

• the physical or digital placement;
• the person or partner responsible for distributing it;
• the creative or call to action you intend to compare;
• the destination or donor path you must test independently.

Do not create a new key for every copy-and-paste. Ten board members sharing the same approved link can use one `board-outreach` key if you only need to evaluate the channel. Give each member a distinct key only when the result would change a real follow-up decision.

Current fundraising products implement this idea differently. GoFundMe Pro documents source codes for comparing links across channels, while Fundraise Up documents UTM parameters on campaign pages and elements. Those examples prove their documented paths, not yours. Use your platform's current fields and preserve the same operating distinction.

Test the complete path, not the URL alone

A correctly formatted link can still lose its source key during a redirect, short-link hop, embedded checkout, or platform handoff. Test the exact asset a donor will use.

For each row in the register:

1. Open the final email link or scan the final printed QR code on a phone.
2. Confirm the intended page and form load without a broken or stale redirect.
3. Complete a permitted test transaction using your normal test procedure.
4. Inspect the transaction, gift record, and analytics report for the expected source value.
5. Record where the value appeared, when it was tested, and who owns a failure.

Route-specific exceptions are normal. For example, Bloomerang's current guidance documents UTM capture for supported fundraising forms and notes that registration forms are not supported. The useful lesson is not about one vendor. A passing donation-page test does not automatically validate an event-registration route.

If the source key disappears before the payment record, keep the link if it is still useful, but lower the attribution claim. Fix the route before promising gift-level reporting.

Label each result by what it proves

Use three evidence levels in the register:

• Link verified: the destination opens and the source key survives the visible URL path.
• Traffic verified: analytics records a click or session under the expected source.
• Gift verified: the completed transaction or gift record contains the expected source value.

These levels prevent a common reporting shortcut. A QR scan shows that someone opened a link. A session shows that a browser reached the page. Neither proves that the same person completed a gift. Report the strongest level your setup actually preserves.

When the gift record does contain the source key, keep the original value unchanged. Correct a misspelled display label in your reporting layer instead of silently rewriting historical gift records and breaking comparison with earlier exports.

Keep the register small enough to maintain

A spreadsheet is enough for a lean team. Use these columns: source key, campaign, medium, placement, destination, owner, tested date, evidence level, and status. Archive a row when the printed asset expires or the destination is retired; do not recycle its key for a different placement.

Before your next appeal, list the actual routes donors will use. CharityStack's Raise product page describes hosted pages, embedded forms, QR codes, and prefilled links. If you are still choosing between a hosted and embedded route, make that decision first with the placement failure-mode guide. Then assign one source key to each placement and test what your chosen route can prove.