Standard Events - WeGive Documentation

WeGive reports checkout milestones to Google Tag Manager (GTM) and, when enabled, Tealium. Your organization configures the triggers, tags, mappings, consent rules, and reporting destinations in its tracking platform. Sending an event to a container does not guarantee delivery to a destination. These events work alongside checkout interaction hooks. Hooks let your scripts observe individual controls; standard events report the application milestones below. Not every checkout layout or authentication path encounters every milestone.

Enable delivery

GTM: configure your Google Tag Manager container in WeGive’s integrations settings. Event timing, payloads, common context, and donor-sharing controls are described below. Ecommerce messages use the checkout document’s window.dataLayer; interaction events use the GTM plugin. Tealium: configure the account, profile, and environment in the Tealium integration, then enable Send standard checkout events. This toggle defaults to off. The environment defaults to prod when blank. Page-view tracking works independently of this toggle. If your Tealium profile already listens for WeGive data-layer events and forwards them, remove that forwarding before enabling automatic delivery. Otherwise the same milestone can be reported twice. GTM and Tealium can run together; either can receive its events independently of the other.

Event catalog

Event	When it is reported	Payload facts
`begin_checkout`	Single-page initialization, or advancement from the stepper’s Giving step.	Ecommerce currency, value, designation items; donation frequency.
`add_payment_info`	Payment-information milestone: submission in single-page checkout, or Billing advancement in the stepper. Eligibility varies by payment path.	Ecommerce currency, value, payment type; donation frequency.
`givingDetails`	Advancement from the Giving step.	Amount and frequency; V1 also includes currency code in `value`.
`personalInformationSignIn`	Checkout sign-in continuation. V1 also reports this on its guest continuation.	Interaction envelope.
`personalInformationSignUp`	Checkout signup completion.	Interaction envelope.
`giveAsGuest`	Donor chooses guest continuation.	Interaction envelope.
`verificationSent`	Authentication code sent.	Interaction envelope; verification type when supplied.
`verificationCompleted`	Authentication code verified.	Interaction envelope.
`paymentInformation`	Advancement from Billing.	Interaction envelope.
`changedNewPaymentType`	Type of payment method being added changes.	Interaction envelope; payment type.
`addedCard`	Card-added milestone.	Interaction envelope.
`addedBank`	Bank-added milestone.	Interaction envelope.
`addedOtherPaymentType`	Alternative-payment continuation.	Interaction envelope.
`confirmOneTime`	Donor chooses the one-time option at a conversion prompt.	Amount and frequency.
`convertRecurringYearly`	Donor chooses a recurring option at a conversion prompt. Despite its name, this event applies to all supported recurring frequencies.	Chosen frequency. This is a choice, not proof that a plan was created.
`donationConfirmed`	Donation-completion continuations.	Donation interaction envelope below. This is not a strict settled-payment signal.
`purchase`	Donation and registration ecommerce-completion continuations.	Ecommerce transaction ID, currency, value, items; donation/registration facts. This is not a strict settled-payment signal.
`donationSuccess`	The browser receives a transaction explicitly marked successful by WeGive, including a required verification response.	Outcome envelope below.
`recurringPlanCreated`	A new recurring plan is created, including a post-payment conversion.	Outcome envelope describing one configured installment.
`registrationConfirmed`	Event-registration completion; outside donation-only checkout.	Registration amount, currency, campaign/event/registration IDs, transaction reference, quantity, status, frequency and fee coverage.
`personalInformation`	Standalone password sign-in tracking; outside donation-only checkout.	Interaction envelope.

Event availability varies between V1, V2, stepper, single-page, and payment paths. A wallet path that bypasses the purchase milestone does not emit that event. Its qualifying payment/plan response can produce donationSuccess or recurringPlanCreated. No session_start, login, signup, guest_login, donation_result, or session-UUID-ready event is part of this catalog.

GTM payloads

Interaction messages use the plugin serialization: event, target (category), action, target-properties (label), interaction-type (noninteraction), and optional value. Some V2 events have no label. GTM includes authentication contact fields under Existing fields only or Expanded donor details; Off suppresses them. Native Tealium does not copy these authentication contact fields; it uses its own independently gated donor fields. Ecommerce messages use { event, ecommerce, donation }. An { ecommerce: null } message precedes each ecommerce event to clear previous values. Ecommerce amounts and item prices are in major currency units; donationConfirmed.value.amount is in integer cents. donationSuccess and recurringPlanCreated use the donationConfirmed interaction envelope with these nested value fields:

Field	Meaning
`amount` / `amount_dollars`	Integer cents / major units. Successful payment total including covered fees, or one configured recurring installment including configured covered fees. Never the lifetime plan total.
`currency_code`	Uppercase currency for that returned payment or plan.
`is_anonymous` / `anonymous`	`is_anonymous` is a boolean. The `anonymous` alias preserves the checkout’s source value and type; use `is_anonymous` when a boolean is required.
`fee_covered` / `coverFees`	`fee_covered` is a boolean. The `coverFees` alias preserves the checkout’s source value and type; use `fee_covered` when a boolean is required.
`campaignId`	Campaign ID, or `null`.
`designationName` / `designationId`	Primary designation name / ID, or `null`.
`frequency`	`once` or the recurring frequency; the plan-created event uses the created plan’s frequency.
`transactionId`	Actual initial transaction ID, or `null` if there is no initial transaction.
`transactionStatus`	Numeric WeGive status, or `null`. Only `2` qualifies for `donationSuccess`.
`scheduledDonationId`	Actual recurring-plan ID; required for plan-created and otherwise `null` when absent.
`correlation_id`	Returned transaction correlation reference as a string, or `null`. Never replaced with a transaction, plan, session, or Meta event ID.

For example, a GTM Custom Event trigger can match donationSuccess, with Data Layer Variables value.amount_dollars, value.currency_code, and value.transactionId:

{
  "event": "donationSuccess",
  "target": "Checkout",
  "action": "click",
  "target-properties": "Single Page Donation Confirmation",
  "interaction-type": false,
  "value": {
    "amount": 2600,
    "amount_dollars": 26,
    "currency_code": "USD",
    "is_anonymous": false,
    "anonymous": false,
    "fee_covered": true,
    "coverFees": true,
    "campaignId": null,
    "designationName": "General Fund",
    "designationId": 7,
    "frequency": "once",
    "transactionId": 42,
    "transactionStatus": 2,
    "scheduledDonationId": null,
    "correlation_id": "example-transaction-reference"
  }
}

Tealium payloads

WeGive calls utag.link(payload) with the same event name in tealium_event. It does not specify tag UIDs or bypass your profile’s routing rules. See Tealium’s tracking API. The payload uses flat UDO variables:

Source fact	Tealium variable
Event name	`tealium_event`
Category, action, label, noninteraction	`event_category`, `event_action`, `event_label`, `event_noninteraction`
Donation/interaction `value` field	`value_` plus its field name, such as `value_amount_dollars`, `value_transactionId`, `value_correlation_id`
Ecommerce currency, value, transaction ID, payment type	`ecommerce_currency`, `ecommerce_value`, `ecommerce_transaction_id`, `ecommerce_payment_type`
Item IDs, names, prices, quantities	Aligned arrays: `ecommerce_items_item_id`, `ecommerce_items_item_name`, `ecommerce_items_price`, `ecommerce_items_quantity`
Donation frequency, anonymity, fee coverage, campaign	`donation_frequency`, `donation_is_anonymous`, `donation_fee_covered`, `donation_campaign_id`
Registration ecommerce facts	`donation_is_registration`, `donation_campaign_event_id`, `donation_registration_id`, `donation_status`, `donation_quantity`

Units and scalar types match the source facts. Explicit nulls remain null; absent fields are omitted. Missing item attributes become null at their array position. The base event mapping uses a non-contact allowlist, excluding donor names, email, phone, addresses, and the destination of an authentication code. When Tealium donor sharing is enabled, separately allowlisted donor_* fields are added as described in the sharing guide. Custom-field answers and payment credentials are not forwarded. In Tealium, define the relevant UDO variables and configure your tag/event mapping for tealium_event equal to donationSuccess. The preceding example is delivered with value_amount: 2600, value_amount_dollars: 26, value_currency_code: "USD", value_transactionId: 42, value_transactionStatus: 2, and value_correlation_id: "example-transaction-reference", along with the other permitted fields. This is an example of WeGive’s automatic payload, not a second utag.link call to add to your profile.

Select the reporting signal

Use donationSuccess for explicit successful-payment reporting. Pending, processing, failed, missing, or unknown statuses do not qualify. HTTP success alone does not qualify.
Use recurringPlanCreated to count newly created plans. A deferred plan can have no initial payment. A pending initial transaction retains its actual ID/status in this event. Updating an existing plan does not create another plan-created event.
An immediate successful recurring gift can produce both donationSuccess and recurringPlanCreated. Count the payment and the plan as different measures.
Avoid counting donationConfirmed, purchase, and donationSuccess as three separate gifts. donationConfirmed and purchase can report completion paths that are not strictly settled payments.

donationSuccess and recurringPlanCreated are deduplicated by organization, event type, and returned record ID for the current page lifetime, including component remounts. This deduplication applies specifically to those two outcome events. A post-payment conversion reports the newly created plan without repeating the initial donation-success signal. These are browser events, not a settlement feed. A payment that settles after the donor leaves does not generate a later browser success event. Native Tealium delivery buffers at most 100 events for up to 15 seconds while its SDK loads; events can be lost if the page closes, the SDK stays unavailable, the setting/profile changes, or a vendor call fails. Events are never redirected to another organization’s loaded profile. Outcome events depend on the transaction status and plan identifiers returned by the WeGive API. The correlation reference is provided for matching records; it does not itself perform a Salesforce lookup or establish equivalence with a Salesforce receipt identifier.

Shared context and optional identity

All standard events include the common context: nested wegive in GTM and flat wegive_* variables in Tealium. Events emitted before session creation completes can contain a null UUID. Donor sharing is independent per integration; explicit GTM opt-out also suppresses authentication contact fields. Common wegive / wegive_* context contains no donor contact fields. GTM uses separate wegive_donor and wegive_user_data namespaces in Expanded donor details mode; Tealium adds donor_* fields only under its own sharing setting. Context-only updates have no event key and do not fire a conversion.

​Enable delivery

​Event catalog

​GTM payloads

​Tealium payloads

​Select the reporting signal

​Shared context and optional identity