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 left to right. Confirm the data exists in Vendo before debugging the downstream platform.

Quick Triage

Step 1: Check Destination App Health

Open the destination app or integration detail and confirm:

• 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 rerunning the sync.

Step 2: Check the Source Output

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

For model-based syncs:

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

For segment-based syncs:

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

For event-based syncs:

• Confirm source syncs are fresh
• Check event name filters
• Confirm 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 Resolution.
2. Confirm the source that provides the identifier is active.
3. Confirm 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:

• 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 before sending the full model output.

Step 5: Check Schema Drift

Schema drift happens when a source/model output changes after the destination mapping was configured.

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
• A nested object or array is no longer supported by the destination

What to do:

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

Step 6: Check Job Logs

Use the job logs to identify 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 intentionally disabled 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:

• 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 destination’s limits

Messaging Destinations

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

Check:

• 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:

• PII is hashed as required
• Click IDs or conversion IDs are mapped when used
• 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 are increasing over time
• One source or segment suddenly drops to zero
• A schema or mapping changed before the drop

Recovery Checklist

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

Related

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