What should a direct mail event payload include?

What is a direct mail event payload?

A direct mail event payload is the structured data package that enters an event-to-mail workflow. It explains what happened, which record qualified, who may receive mail, which creative should be used, and which checks must pass before release.

The payload is not the postcard itself. It is the operational context around a potential send. A clean payload lets the workflow evaluate address readiness, suppression, duplicate-send windows, proof state, campaign metadata, and later review records without guessing from screenshots or exports.

When should teams create the event payload?

Create the event payload at the moment a source-system event becomes eligible for review, not after the mail batch is already built. The earlier the payload is created, the easier it is to explain why a record moved forward or stopped.

For example, a payload might be created when a cart becomes abandoned, a lead changes status, a customer qualifies for a thank-you card, or a record enters a reactivation audience. The workflow can then decide whether the record is complete enough to mail, should be held for review, or should be suppressed.

What fields should a direct mail event payload include?

A useful payload includes enough fields to identify the source event, evaluate mailing eligibility, render the postcard safely, join tracking records, and explain the final release decision.

How should address fields be handled?

Address fields should be stored as structured values, not one mixed text blob. USPS addressing references separate delivery address lines, city, state, ZIP Code, secondary-unit information, and other address elements that operators need to review.

The payload should keep the original address from the source system and the reviewed mailing address separately when both exist. That distinction helps operators explain whether a record was standardized, held for secondary-unit review, suppressed, or released. For more on address readiness, see the mailable address guide.

How should creative and merge fields be recorded?

The payload should name the creative version and list the variable fields used to render the postcard. It should also preserve fallback values for missing fields so the proofing step can catch unsafe or confusing personalization.

Direct mail has a physical layout, address area, barcode area, and visible copy. A payload that only says “send template A” is usually too thin. Operators need to know which fields were merged, which values were missing, which proof version was approved, and whether the final rendered postcard matches the release record.

For proofing context, see the print proof guide and the postcard template guide.

How does the payload connect to send rules, campaign IDs, and batches?

The event payload supplies the data. The send rule decides whether the data is eligible. The campaign ID groups the mailing effort. The batch ID records one approved release of mail records.

For the decision logic, see the direct mail send rule guide. For the campaign-level join key, see the campaign ID guide.

How should tracking fields be joined later?

The payload should preserve campaign, batch, recipient, and source-record keys so mailstream tracking fields can be joined back to the original event. USPS Intelligent Mail barcode and Informed Visibility references describe postal visibility systems; the payload keeps your workflow context attached.

Keep this boundary clear. A tracking join can help operators review the mailstream. It does not prove that the recipient saw the piece, responded to it, or generated revenue. Those outcomes require separate response sources, declared measurement windows, and review logic.

What should a direct mail event payload not prove?

A direct mail event payload should not prove delivery, recipient exposure, response, attribution, revenue, or lift. It is an operational record for eligibility, proofing, release, tracking joins, and later review.

Overloading the payload creates false confidence. The safest pattern is to keep each record type honest: event payload for source context, send rule for eligibility, proof for creative review, batch for release, tracking record for mailstream signals, and measurement window for outcome review.

What should a Sendvo-style workflow keep visible?

A Sendvo-style workflow should keep the event payload visible beside send rules, address checks, suppression results, proof versions, campaign IDs, batch IDs, tracking fields, and measurement windows before the record is reviewed.

Sendvo is in beta, so product language should stay capability-framed. The operational pattern is stable: when teams connect audience data, postcard design, triggered sends, and USPS tracking, the event payload becomes the data contract that explains why a postcard was considered, held, approved, released, or reviewed later.