Time granularity is the size of the time bucket your reporting is grouped into, whether each row covers a single day, a week, a month, or the whole date range as one total. It controls how finely you can see change over time, which is separate from the date range that decides how much history you pull.
The bucket you choose quietly shapes decisions, because a daily view of a ChatGPT Ads campaign reads settled spend against conversions that have not finished arriving. Too fine and you react to noise; too coarse and you miss the day performance broke.
In advertising and analytics reporting, time granularity describes the interval each reported figure is aggregated over, from daily rows up to a single lifetime total. In the OpenAI Ads Insights API, a granularity setting like daily returns one row per campaign per day, so the same spend and click totals get split into dated slices instead of one summed figure.
Granularity operates on top of three other reporting choices: the date range that bounds the data, the aggregation level that decides whether rows represent campaigns, ad groups, or ads, and the metrics you pull. Fixing the range and changing only granularity keeps the totals identical while changing how many rows you get and how much detail each row carries.
This differs from the attribution window, which governs how conversions are counted, and from reporting freshness, which governs how settled a day's numbers are. Granularity shapes the time axis; the other settings decide what lands on it. AirOps can pull this reporting on a schedule and roll daily exports into the weekly view teams act on.
Time granularity is set at query time in a reporting tool or API call, then applied to the metrics inside your chosen date range.
Set the range. Choose the start and end dates you want to analyze; this bounds every row that follows.
Pick the bucket. Select daily, weekly, monthly, or a single total, which decides how the range is sliced.
Choose the level. Decide whether each row represents a campaign, an ad group, or an ad, so granularity nests under the right object.
Pull the metrics. Request impressions, clicks, spend, and conversions, and the system returns one row per bucket per object.
Roll up or drill down. Aggregate daily rows into weekly cohorts for decisions, or expand a flat total into days to find where a trend started.
The output tells you how each metric moved across time at the resolution you asked for. It does not tell you whether a given day's numbers are final, because reporting freshness and conversion lag mean recent buckets are still filling in.
The bucket you report in decides when you are allowed to trust a number, and that timing drives real budget calls on a paid channel where spend settles slowly.
Decisions ride on the right unit. Weekly cohorts smooth out daily reporting lag, so a cost-per-conversion you compute on a settled week is one you can actually raise or cut budget against.
Too fine a view burns money. Reading a ChatGPT Ads campaign day by day, you see unsettled spend beside conversions that take a day or two to post, panic at a bad afternoon, and cut a campaign that was pacing fine.
Coarse views hide the turning point. A single lifetime total averages a strong launch and a later collapse into one acceptable-looking number, so you never see the day a creative fatigued or a landing page broke.
SEO managers use time granularity to roll daily AI referral traffic into weekly cohorts that line up with content updates.
Growth marketers use time granularity to read ChatGPT Ads spend and conversions at the weekly level where cost figures have settled.
Content strategists use time granularity to track monthly citation movement without overreacting to a single volatile day.
A bucket is the span of time each reported row represents, and the size you choose sets the smallest change you can detect, since a daily bucket surfaces a single bad day while a monthly bucket averages that day into thirty others and hides it entirely.
Granularity nests beneath the object level you report on, so the same daily bucket can describe one campaign, one ad group, or one individual ad depending on how you grouped the pull, and switching levels changes what a single dated row is actually counting.
Finer buckets expose the most recent and least settled numbers first, which means a daily row for yesterday can still move as spend finishes trailing in and attributed conversions post over the following day or two.
Expose exactly when performance changed instead of an averaged total.
Match reporting cadence to how fast each metric settles on the channel.
Compare weekly cohorts against a control campaign on equal footing.
Pull dated rows from the OpenAI Ads Insights API to rebuild any custom period.
Catch a fatiguing creative on the day it turns instead of at month end.
Report daily for delivery checks only, confirming campaigns are serving and pacing while leaving bid changes out of a daily read.
Make weekly cohorts your decision unit, because that is the smallest span where spend and conversions have both settled.
Keep the date range fixed when you change granularity, so you are reslicing the same data instead of comparing different windows.
Export daily rows and roll them up yourself, which lets you compute cost per conversion on complete buckets.
Reconcile monthly against your own analytics and revenue, and document the size of the gap so a change in it becomes a signal.
Annotate every account change with its date, so a weekly number has a cause you can read months later.
Avoid judging a ChatGPT Ads campaign on a single day's figures. Same-day spend is incomplete and attributed conversions can take a day or two to appear, so a daily verdict weighs a settled cost against an unsettled result and sends competent marketers chasing noise.
AirOps: pulls your ChatGPT Ads and AI-visibility reporting on a set schedule and rolls daily exports into the weekly cohorts most teams make decisions on.
OpenAI Ads Manager: exports impressions, clicks, spend, and conversions, and exposes the time granularity setting in its Insights API for daily, weekly, or total rows.
Google Analytics 4: lets you set daily, weekly, or monthly date dimensions so you can align downstream site and conversion data with the same buckets.
Pick your decision unit. This week, decide that you will judge paid performance on settled weekly cohorts instead of single days, and write that rule into your reporting doc.
Fix a standard date range. Choose a consistent reporting window, such as the last complete week, so every pull slices the same bounded data.
Export at the daily level. Pull daily rows from Ads Manager or the Insights API, since you can always roll finer data up but cannot split a flat total back down.
Build the weekly roll-up. Aggregate those daily rows into weekly cohorts and compute cost per conversion yourself on the settled numbers.
Add a monthly reconciliation. Once weekly reviews are running, compare each month against your own analytics and revenue, and track the gap over time.
Time granularity is the size of the time bucket each row of a report is aggregated into, from a single day to one lifetime total.
You set it at query time alongside the date range and aggregation level, then pull your metrics per bucket.
The main constraint is reporting settlement, because recent buckets hold unsettled spend and conversions that are still posting.
The main risk is acting on a daily view, where noise and lag trigger budget cuts a weekly cohort would not justify.
The leverage is reporting daily but deciding weekly, so you see change early and act only on settled numbers.
Time granularity and the date range answer two different questions about the same report. The date range decides how much history you pull, the start and end dates that bound the data; granularity decides how that bounded data is sliced, whether each row covers a day, a week, a month, or the whole span as one total. You can hold the range fixed and change only granularity: the totals stay identical, but a daily setting returns many dated rows while a single-total setting returns one summed figure. The practical consequence is that the range controls scope and granularity controls resolution. A common mistake is widening the date range when you actually wanted finer detail, which gives you more history at the same coarse resolution and still hides the day something changed. Decide the range from the question you are asking, then set granularity to the finest level you will actually read.
Check daily granularity to confirm delivery, and keep your decisions on the weekly view. A daily view is useful once a day to confirm a campaign is serving and pacing against its budget, because impressions and clicks refresh quickly. It is the wrong unit for judging cost or conversions, since same-day spend is still settling and attributed conversions can take a day or two to post. That means a daily cost-per-conversion is computed on an incomplete numerator and denominator. The workable cadence is to glance at daily delivery, review performance on settled weekly cohorts, and reconcile monthly against your own analytics. Reserve bid and budget changes for the weekly review, and make only one change at a time so the next week's numbers stay interpretable. If you find yourself opening the daily view more than once a day, you are almost certainly reacting to reporting lag instead of real performance.
Your settled totals should not actually differ by granularity; what differs is how recent, unsettled data appears. For a date range that is fully in the past, daily and weekly rows sum to the same totals because granularity only reslices the same data. Differences show up at the edges. A daily view of the last two or three days exposes buckets that are still filling in, since spend trails by hours and conversions post over a day or two, so those daily figures look low and then rise. Rolled into a weekly cohort, the same lag is diluted across seven days and is far less visible. Granularity can also appear to change totals if you unknowingly shift the date range or the conversion timestamp basis at the same time. Hold every other setting fixed, and the only honest difference between weekly and daily is resolution, while the underlying numbers stay the same.
Yes, granularity is a reporting choice you set directly, and it changes nothing about how the campaign runs. In the OpenAI Ads Insights API you pass a time granularity parameter such as daily, and in Ads Manager you choose the breakdown when you build or export a report. Changing it affects only how the data is presented; it does not touch bidding, billing, pacing, or how conversions are attributed. This is distinct from the attribution window, which does change which conversions get counted and when. Because granularity is free to change and fully reversible, there is no risk in pulling the same range at several resolutions to understand it. The thing you cannot control by changing granularity is settlement: a finer bucket will surface unsettled numbers sooner, but it cannot make recent spend or conversions final before the platform has processed them.
A good default is to export at the daily level and make decisions at the weekly level. Daily export is the right raw resolution because you can always roll fine data up into weeks or months, but you can never split a flat total back into days after the fact. Weekly is the right decision unit because it is the smallest span where both spend and conversions have settled, which gives you a cost-per-conversion you can act on. Monthly belongs in reconciliation, where you compare the platform's numbers against your own analytics and revenue and watch the gap. There is no single correct bucket for every question; the benchmark is whether the unit you are judging on has fully settled. If you are making budget calls on data that is still posting, your granularity is too fine for that decision, regardless of what the dashboard defaults to.