In this guide
- Request Delay holds requests to one path for 1 to 2,000 minutes, then sends them on. The visitor gets an answer at once.
- It helps with offline conversion timing and with making sure a browser event arrives before its server copy.
- It is available from the Business plan.
Most of the time you want events to reach your tagging server immediately. Sometimes you do not. A webhook from a payment provider might arrive before the customer's thank-you page has fired its browser event, which can confuse deduplication. A lead may need time to be checked before it is counted as a conversion. A batch of offline sales should be sent in the order they happened. For those cases, Request Delay lets you hold requests to a specific path for a set number of minutes. This page explains how it works and when it is a good idea. See also event deduplication and how to send offline conversions.
What it does
You give it a path, for example /webhook, and a delay in minutes. Requests to that path, and below it, are accepted and answered at once, so the sender sees a normal success reply. The request itself is then held for the delay and sent on to your tagging server when the time is up. Nothing else is delayed: requests to other paths flow as usual.
| Setting | What it means | Range |
|---|---|---|
| Path to delay | Requests to this path and below it are held | For example /webhook or /mp/collect |
| Delay | How long to hold them | 1 to 2,000 minutes (about 33 hours) |
Check your tracking in one pass
This is an example. Run the check on your own site to see where yours stands.
When it helps
Deduplication order
Meta prefers to see the browser event first. If a server event from a webhook beats it, a short delay on the webhook path lets the browser copy arrive first.
Offline conversion timing
Hold a CRM webhook for a while so a payment or a review can complete before the conversion is sent.
Smoothing bursts
Spread a flood of webhook calls over time rather than hitting your container all at once.
Waiting for data
Give a slow process, such as an address check, time to finish before the event is sent.
When not to use it
- For regular browser events. Delaying page views or add-to-cart events makes real-time reports wrong.
- To hide a broken set-up. If events arrive in the wrong order because of a bug, fix the cause.
- For very long delays that outlive the platform's window. Meta only accepts events within a limited number of days.
3 things to remember
Scroll and the points stack up.
Request Delay holds requests to one path for 1 to 2,000 minutes, then sends them on. The visitor gets an answer at once.
It helps with offline conversion timing and with making sure a browser event arrives before its server copy.
It is available from the Business plan.
Set it up
- Turn on Request Delay (Business plan or above).
- Enter the path to delay, for example
/webhook. - Enter the delay in minutes, from 1 to 2,000.
- Press Save. The rule is applied within a few seconds.
- Press Test this power-up.
Test it
Send a request to the path and check two things. First, the sender gets an immediate answer. Second, the request shows up in your server container (in Preview or the logs) only after the delay. Use a short delay, like 2 minutes, while you test, then set the real value.
A worked example
A store sends its purchase from the browser and also from a payment webhook. The webhook usually arrives a few seconds before the thank-you page finishes loading, so Meta sometimes sees the server event first and keeps the later browser event as a second purchase. The team adds a 2-minute delay to the webhook path. The browser purchase now arrives first, the server copy follows with the same event ID, and Meta deduplicates them. The visitor is not affected, and the numbers stop jumping.
Questions to ask before you add a delay
Ask what you are trying to fix. If the answer is "events arrive in the wrong order", find out which two events and where each one comes from. A delay on the earlier-arriving path is the right tool. If the answer is "I want to wait for the CRM to finish", check whether the CRM can send the webhook later instead, which is simpler. If the answer is "I want fewer requests", a delay does not help, because the requests still arrive, just later.
Ask how long a delay is safe. Platforms accept events only within a limited window, so a delay of hours or days eats into it. For deduplication, a delay of a minute or two is usually enough. For offline timing, choose the shortest period that lets the other process finish. Write the reason and the value in your container notes, so the next person does not remove it by accident or increase it without knowing why.
Terms you will see
- Path
- The part of the web address after the domain, such as /webhook.
- Webhook
- A message a system posts to your server when something happens.
- Deduplication
- Counting a browser event and its server copy once.
- Event window
- How old an event may be when a platform accepts it.
Orders from your store, back to the ad that earned them
Your store sends the order once. Open Tracked passes it on to each ad platform, cleaned and deduplicated.
Frequently asked questions
What does Request Delay do?
It holds requests to a chosen path for 1 to 2,000 minutes, then sends them to your server container. The sender gets an immediate answer.
Which plan includes it?
Business and above.
Does it delay all my tracking?
No. Only requests to the path you set, and below it.
How long can the delay be?
Up to 2,000 minutes, a little over 33 hours.
Why would I delay a request?
To control the order of events for deduplication, to time offline conversions, or to smooth bursts.
Do I need spreadsheets to read my results?
No. Once tracking is live, the Open Tracked analytics shows spend, revenue, ROAS and profit, and you can ask Ari, the built-in AI assistant, questions about your own numbers in plain words. Ari's allowance depends on your analytics plan.
Is Open Tracked different from Open Track or Open Space Track?
No. Open Tracked is the official name of our server-side tracking platform, and the website is opentracked.io. Many people search for it as Open Track, OpenTrack or Open Space Track. All of them lead to the same product: server-side Google Tag Manager hosting, first-party analytics and a CRM pipeline.
Fix your tracking at the source
Open Tracked hosts your server-side Tag Manager, keeps first-party cookies alive and shows what each ad is really worth.
The Open Tracked team
We build Open Tracked: server-side tracking hosting, analytics and the tools around them, for stores that spend on ads. Questions about this guide, or an idea for the next one?
Comments
Loading comments...
Guides · 6 min read
