Understand event delivery
See whether an action succeeded, Tyton accepted it, and Meta received it.
Start with the business record
Use your order or submission record to confirm what happened. A paid order remains paid even if tracking fails.
Read each result at its own boundary
| Result | What it establishes |
|---|---|
| Pixel ID saved | Tyton stored the destination ID. |
| Token saved | Tyton stored the encrypted credential. Delivery is checked when Meta accepts an event. |
SDK verified | A planned tracking call reached Tyton in test mode; nothing was sent to Meta. |
SDK stored | Tyton saved checkout context, not a conversion. |
SDK queued / HTTP 202 | Tyton accepted the event for delivery. |
Pixel dispatched | The browser called fbq; Meta receipt is still unconfirmed. |
Sent to Meta / sent | Meta accepted the CAPI event. |
Retrying / retryable | Tyton will try again after a recoverable failure. |
rejected | Delivery was rejected; check the reason. |
uncertain / SDK unknown | Tyton could not confirm whether it was accepted. |
Browser Purchase can be observation-only, and a paired source can share a delivery owned by the other source. Neither state means two CAPI deliveries.
Investigate in order
- Confirm business success and the expected event identity.
- In Events, choose the right site and time range. Check whether the event came from browser or server and read its detailed status. If Events cannot load, refresh or contact support to check the activity.
- Confirm destination receipt in Meta Test Events. Attribution and reporting are separate checks in Meta.
Tyton can retry known temporary failures, including token problems after you repair the credentials. If Meta’s response is uncertain, Tyton does not blindly resend it: Meta might already have accepted it. Do not create a new event ID to make it look successful.
The dashboard can show two source badges on one event row. Overview’s recent sample is not a complete history. Use troubleshooting when the business record and tracking evidence differ.