Why Your "Today" Numbers Don't Match: Timezones in Marketing Reporting

You open Meta Ads Manager and it says you spent $1,240 today. Your attribution dashboard says $980. Stripe says you took in $6,000 today; your CRM’s “closed today” view says $9,000. Nobody’s data is wrong. Each tool is drawing “today” from a different midnight. Timezones in marketing reporting are one of the most common, least discussed reasons numbers don’t reconcile, and they get worse the more tools, team members and countries you add.

This post explains where each part of a typical stack takes its timezone from, the specific ways mismatches distort reports (especially for businesses that book calls in the evening), how to pick one reporting timezone and make everything line up, and a quick test to tell a timezone problem from a tracking problem.

Every tool has its own midnight

A day in a report is a 24-hour window with a start and end. The question is: midnight where? Different tools answer differently.

• Ad accounts. Meta ad accounts and Google Ads accounts each have a timezone set when the account was created, and it’s generally difficult or impossible to change afterwards. Spend, clicks and platform-reported conversions are all bucketed by that timezone. Agencies inheriting client accounts often find one set to Pacific, another to London, a third to wherever the original freelancer lived.
• Payment processors. Stripe, Whop, Kajabi and others have an account timezone for their dashboards and reports, which may differ from how they timestamp individual payments (often UTC under the hood).
• CRMs and calendars. GoHighLevel, HubSpot and Close typically use a location or account timezone for reports, while each user sees their own calendar in their own local time.
• Analytics. GA4 properties have a reporting timezone set at the property level.
• Attribution and BI dashboards. Some use UTC, some use the browser’s timezone, some use an account setting.
• Spreadsheets and exports. A CSV usually has raw timestamps, often UTC, and whoever builds the pivot table decides the day boundaries, frequently without realizing it.

So “today” in a stack of six tools can mean six slightly different windows.

How the mismatch distorts your numbers

The evening shift

The most common symptom is activity that happens in the evening landing on the next day. Consider a US business whose dashboard counts days in UTC. UTC midnight is 8pm Eastern (during daylight saving time) or 5pm Pacific. Every lead, booking and sale after that time is filed under tomorrow.

For call-based businesses this is a big deal, because a lot of booking happens in the evening when people are home watching a VSL. If 30% of your bookings happen after 8pm Eastern, a UTC-based report will show roughly 30% of each day’s bookings on the following day. Daily cost per booked call becomes noise: spend is counted in the ad account’s timezone, bookings in UTC, so they don’t refer to the same people.

This was a real bug in our own product: the Callix numbers in the Chrome extension used to count each day in UTC, so “Today” in the US started in the late afternoon or evening of the day before, and a call booked that evening landed on the next day. The fix was to make each day in the range run from midnight to midnight in your browser’s timezone, as the Callix dashboard does.

Partial “today”

If your ad account is on Pacific time and you’re in New York, at 9am your “today” in Ads Manager is only six hours old. Spend looks low, cost per lead looks great, and by evening it all normalizes. Making mid-morning budget calls on a partial day in a different timezone is a reliable way to overreact.

Month boundaries

Daily mismatches mostly wash out over a week. Month-end ones don’t, because they move money between reporting periods. A sale at 10pm Pacific on September 30 is October 1 in UTC. If finance reports in UTC and marketing in Pacific, the September ROAS in the board deck and the September revenue in the finance report won’t match, and someone will spend an afternoon finding out why.

Daylight saving time

Twice a year, the offset between UTC and most US and European timezones changes by an hour, and not on the same weekend in both regions. A dashboard that hardcodes an offset (say, UTC minus 5) instead of a named timezone (America/New_York) will drift by an hour for part of the year.

Distributed teams

If the media buyer is in Lisbon, the founder in Austin and the setters in Manila, and each sees the dashboard in their browser’s timezone, they’ll each see slightly different “yesterday” numbers. That’s fine for individual work and confusing for a shared weekly review.

A worked example

Say a coaching business in New York runs Meta ads with an ad account set to Pacific time. Its old dashboard counts days in UTC. On a Tuesday (illustrative numbers):

Source	What it counts as “Tuesday”	Spend	Booked calls
Meta Ads Manager	Midnight to midnight Pacific (3am Tue to 3am Wed Eastern)	$1,200	:
Calendar	Midnight to midnight Eastern	:	14
Dashboard (UTC)	8pm Mon to 8pm Tue Eastern	$1,050	10

The dashboard’s cost per booked call is $105. Using the calendar’s day with Meta’s spend gives $86. Neither is “the” answer, because the windows don’t overlap cleanly. Over a full week the numbers mostly converge, but daily decisions made on any one of these are shaky.

Pick one reporting timezone and stick to it

The fix isn’t to make every tool agree; you often can’t change an ad account’s timezone. The fix is to choose one reporting timezone for decisions and make sure your main dashboard uses it explicitly.

How to choose:

• Single-market business: use the timezone where most of your customers are. That’s where “today” means something to buyers’ behavior.
• Team-centric: use the timezone your sales team works in, so a rep’s “today” matches the report.
• Finance alignment: whatever you choose, make sure finance uses the same one for month-end, or document the difference.

Then:

1. Set the dashboard’s timezone deliberately, not by accident of whichever browser opened it. In Callix this is under Settings → Account settings → Timezone. Today, the date presets, each chart’s days and the CRM’s date filter all follow it. It’s a per-user setting, so a teammate in another country can keep their own; leaving it on Browser timezone works as before.
2. Note the ad account timezones. If they differ from your reporting timezone, write it on the dashboard or in your reporting doc so nobody compares daily figures directly.
3. Prefer weekly and monthly views for decisions. The longer the window, the less the boundary matters.
4. Use named timezones in any custom reporting, never fixed offsets, so daylight saving time is handled for you.
5. Make “this month” end today. A month-to-date view that silently includes future days makes averages look wrong. Callix’s date pickers now stop at today, read in the timezone you set.

Is it a timezone problem or a tracking problem?

Not every mismatch is a timezone issue. A quick way to tell:

• Compare a full week instead of a day. If the gap shrinks dramatically, it’s mostly a boundary problem. If it stays at 20%, it’s tracking.
• Look at the hours. Pull timestamps for a day’s events and check whether the “missing” ones cluster in the evening (timezone) or are spread throughout the day (tracking).
• Check one known event. Find a booking or sale you know happened at 9:30pm and see which day each tool files it under.
• Check daylight saving weeks. If the mismatch changed by roughly an hour’s worth of activity around a DST change, something is using a fixed offset.

If it turns out to be tracking (pixels missing on pages, conversions deduplicated differently, platform modeling), why your attribution data doesn’t match your ad platform’s and how to audit your analytics setup for gaps and double-counting cover the usual suspects.

Timezones and calls specifically

Call-based businesses have a couple of extra traps.

• Booking time versus call time. A call booked at 11pm Monday for Thursday at 2pm belongs to Monday for “booked calls” and Thursday for “calls held.” Make sure each metric uses the right timestamp.
• The prospect’s timezone versus yours. Calendars show the call in the prospect’s local time and the rep’s local time. Reports should use your reporting timezone, regardless of where the prospect is.
• Show rate by day. If calls held are bucketed in UTC and calls scheduled in local time, evening calls can appear as no-shows on one day and shows on the next. Show rate by day then looks erratic for no real reason. See show rate, close rate, cash collected for how to define those metrics consistently.

A one-page timezone policy

Write this down once and share it with marketing, sales and finance:

• Our reporting timezone is (fill in).
• Our Meta ad accounts are on (fill in); our Google Ads accounts are on (fill in).
• Our CRM location timezone is (fill in).
• Daily numbers are for monitoring; decisions use weekly or monthly views.
• Month-end figures are calculated in (fill in) for both marketing and finance.

It takes ten minutes and saves the same argument from coming up every month.