Troubleshooting Destinations

Destinations send modeled Vendo data to tools such as analytics platforms, ad platforms, messaging tools, and warehouses. Most destination issues come from one of five areas: credentials, identity fields, mappings, schema drift, or sync execution.

Use this guide when a destination sync fails, delivers fewer records than expected, or sends data that does not appear correctly in the downstream tool.

Destination Workflow

A destination sync usually follows this flow:

Source data -> Model or segment -> Identity resolution -> Destination mapping -> Sync job -> Downstream tool

If the output is wrong, work from left to right. Confirm that the data exists in Vendo before you debug the downstream platform.

Quick Triage

Step 1: Check Destination App Health

Open the App or the destination detail page and confirm that:

• The App is connected and active
• Credentials have not expired or been revoked
• The destination role is enabled
• The account or project ID is correct
• Required API permissions are granted

If credentials changed in the external tool, reconnect the App before you run the sync again.

Step 2: Check the Source Output

Confirm that the model, audience, or source table contains the rows that you expect.

For model-based syncs:

• Open the model output
• Confirm that the latest run succeeded
• Check the row count and sample rows
• Confirm that the expected columns exist

For audience-based syncs:

• Open the audience
• Confirm that the audience has members
• Check the filters and the refresh schedule
• Confirm that identity fields are populated

For event-based syncs:

• Confirm that source syncs are fresh
• Check the event name filters
• Confirm that timestamp filters do not exclude the expected period

Step 3: Check Identity Fields

Most destinations require at least one stable identifier.

If records are missing identifiers:

1. Check Identity Merge.
2. Confirm that the source that provides the identifier is active.
3. Confirm that the destination mapping points to the resolved identifier.
4. Rerun Identity Resolution.
5. Rerun the destination sync.

Step 4: Check Field Mapping

Open the destination mapping and verify that:

• Required destination fields are mapped
• Source columns are the correct type
• Timestamp fields use the expected timezone
• Numeric fields are not mapped from strings
• Event names match downstream naming conventions
• PII hashing is enabled when required
• Consent or subscription fields are mapped for messaging destinations

If a destination accepts custom properties, start with a small set of high-confidence fields. Then send the full model output.

Step 5: Check Schema Drift

Schema drift happens when a source or model output changes after you set up the destination mapping.

Common causes:

• A model column was renamed
• A source table was refreshed with a new schema
• A destination property type changed
• A required field was removed from the model output
• The destination no longer supports a nested object or array

What to do:

1. Reopen the mapping.
2. Look for missing or invalid fields.
3. If available, refresh the source or model schema.
4. Remap the affected fields.
5. Validate or run a small test sync.

Step 6: Check Job Logs

Use the job logs to find where the sync failed:

• Queued: waiting for the orchestrator or schedule
• Running: sync is in progress
• Completed: delivery finished from Vendo’s side
• Failed: configuration, credential, API, schema, or execution error
• Paused: sync is disabled on purpose, or blocked after repeated failures

If the job failed, read the first error and the final error. The first error usually points to the root cause. The final error may only show the retry state.

Platform-Specific Notes

Analytics Destinations

Examples: Mixpanel, Amplitude, Segment.

Check that:

• Event names are valid
• Distinct/user ID mapping is correct
• Insert ID or event ID is present for deduplication
• Timestamps are not too old for the destination API
• Properties are not nested beyond the limits of the destination

Messaging Destinations

Examples: Klaviyo, OneSignal, Customer.io, Braze.

Check that:

• Email, phone, or platform subscription ID is present
• Consent status is respected
• User properties are mapped to supported field names
• Lists, channels, or workspaces are configured correctly
• Suppressed/unsubscribed users are expected to be excluded

Ad Platform Destinations

Examples: Google Ads, Meta Ads, TikTok Ads, Snap Ads.

Check that:

• PII is hashed as required
• Click IDs or conversion IDs are mapped when used
• The conversion action or event name exists in the ad platform
• Event timestamps are within platform upload windows
• Consent and regional restrictions are handled correctly

Warehouse Destinations

Examples: BigQuery, S3, warehouse exports.

Check:

• Dataset, bucket, or table permissions
• Service account access
• Partition and write mode
• Table schema compatibility
• File naming and export path

When Counts Do Not Match

Small count differences are normal when downstream tools deduplicate, reject invalid identifiers, apply attribution windows, or delay processing.

Investigate if:

• Vendo completed records are much higher than downstream accepted records
• Rejection counts increase over time
• One source or audience suddenly drops to zero
• A schema or mapping changed before the drop

Recovery Checklist

1. Confirm that destination credentials are active.
2. Confirm that source/model output has rows.
3. Confirm that required identity fields exist.
4. Confirm that destination mappings are valid.
5. If resolved IDs are required, rerun Identity Resolution.
6. If possible, run a small test sync.
7. Rerun the full sync.
8. Monitor the next scheduled job.

Related

• Troubleshooting Syncs and Credentials
• API Destinations
• Identity Merge
• BigQuery Destination
• Mixpanel Destination
• OneSignal Destination