OneView automatically handles Conversion API errors and retries failed requests. No action required.
What is Conversion Replay?
Conversion Replay combines contextual error handling with automatic retries to ensure conversions always flow correctly to their destinations. OneView’s stateful architecture guarantees that once an event is accepted, it will eventually reach its destination—even during extended outages.Understanding the problem:Traditional tracking solutions lose data permanently when server timeouts occur, temporary connectivity issues drop events, or endpoint unavailability blocks conversion data. Proxy solutions like GTM Server-Side are stateless by design—the browser cannot guarantee it will always retry a failed event, leading to irrevocably inconsistent data across your marketing platforms.Each advertising platform also has unique API error codes, configuration requirements, and attribution model compatibility rules. Without contextual error handling, you must manually interpret and resolve each platform’s specific errors.
How Conversion Replay works
OneView operates a high-throughput global queue system that classifies errors and applies platform-specific resolution strategies:| Error Type | Classification | Action |
|---|---|---|
| Transient errors | Network issues, temporary outages | Automatic retries with exponential backoff |
| Rate limit errors | API rate limits exceeded | Retries with backoff to respect limits |
| Fatal errors | Configuration issues, incompatible settings | Retries stopped, requires fix |
| Skipped events | Intentional skips (consent, lookback windows) | No retry, recorded for observability |
Once an event is accepted by OneView, you’re guaranteed it will eventually reach its destination, even if downstream services experience extended outages (up to 7 days).
Error classification
OneView classifies integration responses into normalized outcomes.Transient errors
Temporary failures that OneView automatically retries:| Cause | Example | Resolution |
|---|---|---|
| Network issues | Connection timeout | Automatic retry with backoff |
| API outages | Platform temporarily unavailable | Retries until service recovers |
| Rate limits | Too many requests | Retries with exponential backoff |
No action is typically required. If transient errors persist for prolonged periods, review rate limits and batch sizes for the specific integration.
Fatal errors
Non-retryable problems that require configuration changes:| Cause | Example | Resolution |
|---|---|---|
| Misconfiguration | Webhook misconfigured | Fix configuration, reprocess |
| Incompatible settings | Attribution model conflict | Align settings, reprocess |
| Validation errors | Invalid data format | Fix data format, reprocess |
Skipped events
Intentional skips to prevent errors or policy violations:| Reason | Example | Behavior |
|---|---|---|
| Consent not granted | ad_storage denied | Event skipped, no retry |
| Lookback window exceeded | Conversion outside click-through window | Event skipped, no retry |
Skipped events are acknowledged by the pipeline (no retry). They are recorded for observability and do not count as failures.
Platform-specific handling
Each Conversion API integration is context-aware and handles platform-specific requirements:| Platform | Automatic Handling |
|---|---|
| Google Ads | Attribution model compatibility, Enhanced Conversions requirements |
| Meta | Consent mode enforcement, event matching rules |
| Microsoft Ads | Conversion goal configuration, lookback window validation |
| TikTok | Event schema validation, attribution settings |
OneView automatically adapts error handling to each platform’s API specifications, ensuring conversions flow correctly regardless of platform-specific quirks.
Benefits
No data loss Unlike stateless proxy solutions, OneView’s stateful architecture ensures events are never lost due to temporary network issues or endpoint failures. Automatic recovery OneView automatically retries transient errors and resolves configuration conflicts without manual intervention. Platform-specific intelligence Each integration understands its platform’s error codes, requirements, and behaviors, applying appropriate resolution strategies. Consistent reporting By guaranteeing delivery, OneView ensures your marketing platforms receive all conversions, preventing discrepancies between your dashboards and platform reports.Common questions
How long does OneView retry failed requests?
How long does OneView retry failed requests?
OneView retries failed requests for up to 7 days. This covers most temporary outages while preventing indefinite retry loops for permanent failures. After this period, permanent failures are marked as fatal errors and require configuration fixes.
What happens when OneView encounters a fatal error?
What happens when OneView encounters a fatal error?
OneView stops retrying and marks the event as a fatal error. The pipeline may pause the affected webhook to prevent repeated failures. Once you fix the configuration and resume the webhook, you can reprocess affected conversions.
What happens if an endpoint is down for more than 7 days?
What happens if an endpoint is down for more than 7 days?
After 7 days, OneView stops retrying and drops the event. Some Conversion APIs (such as Meta) do not accept data past 7 days prior.
How does this differ from browser-based retries?
How does this differ from browser-based retries?
Browser-based tracking cannot guarantee retries because users may close the browser before retry completes, network conditions may prevent retry attempts, and no persistent queue exists to ensure eventual delivery. OneView’s server-side queue system persists events independently of user actions, guaranteeing delivery.
Can I see error details and retry attempts in logs?
Can I see error details and retry attempts in logs?
Yes. OneView logs show error classifications, reasons, and resolution actions for each integration, allowing you to monitor and troubleshoot issues. Retry attempts are visible while ongoing, and the final result appears in your reports once delivered.
What if transient errors persist after automatic retries?
What if transient errors persist after automatic retries?
If transient errors persist for prolonged periods, review rate limits and batch sizes for the integration, network connectivity and endpoint availability, and platform-specific requirements and recent API changes.