---
title: "Performance by hour and day of week"
method: POST
path: "/api/v1/tools/google_get_hourly_performance/execute"
tags: ["Google Ads"]
---

# Performance by hour and day of week

`POST /api/v1/tools/google_get_hourly_performance/execute`

## Request

- Base URL: `https://adako.ai`
- URL: `https://adako.ai/api/v1/tools/google_get_hourly_performance/execute`
- Auth: HTTP bearer

Splits performance by hour of day and by day of week, in the account timezone. This is the evidence a schedule decision needs.
Use when: the user is thinking about dayparting, or asks when their ads perform best.
Do not use when: there is little data. Splitting a month across 168 hour-and-day buckets leaves most of them empty, and acting on an empty bucket is how campaigns lose their best hours.
Returns the hour-of-day table and the day-of-week table separately, because the full 168-cell grid is almost never readable or reliable. Hours are in the account timezone, which may not be the user's.
Before recommending a schedule, check the bidding strategy: Smart Bidding already varies bids by time of day, so a schedule mostly removes volume rather than improving efficiency.
If you are unsure which account, campaign or period the user means, ask them — do not guess ids or dates.

## Headers

- `Idempotency-Key` string

## Request body

- object
  - `arguments` object
    - `customer_id` string: Google Ads customer id (10 digits, dashes optional). Omit to use the primary account; list_connected_accounts shows the valid ids.
    - `campaign_id` string: Limit to one campaign.
    - `date_range` 'today' | 'yesterday' | 'last_7_days' | 'last_14_days' | 'last_30_days' | 'this_month' | 'last_month': Preset range. Alternatively pass start_date and end_date (YYYY-MM-DD). Never both.
    - `start_date` string: First day of the period (YYYY-MM-DD). Use with end_date.
    - `end_date` string: Last day of the period (YYYY-MM-DD). Use with start_date.

## Response `200`

The tool ran. A write returns proposal_id and approve_url while the change waits for approval.

- SuccessEnvelope
  - `success` unknown, required
  - `tool` string, required
  - `data` object, required: Machine-readable result.
  - `markdown` string, required: The same result written for a person or a model.
  - `quota` Quota: Task usage for the current billing period.
    - `plan` string
    - `used` integer
    - `limit` integer
    - `period_end` string
    - `upgrade_url` string
  - `proposal_id` string: Present for writes. Nothing changes on the ad platform until it is approved.
  - `approve_url` string: Where a person approves the proposal.
  - `request_id` string, required

## Other responses

- `400`: Invalid arguments, or the ad account could not be resolved.
- `401`: Missing, invalid, revoked or expired API key.
- `402`: Monthly task quota used up, or the plan does not include this tool.
- `403`: The connected ad account lacks the access level this tool needs.
- `404`: Unknown tool name.
- `409`: Not connected, reconnect needed, confirmation required, a proposal already pending or no longer pending, an identical create that failed earlier today (proposal_failed_before), a create that duplicates an approved one (duplicate_create), the ad-account limit of the plan reached (account_limit), or an Idempotency-Key reused with different arguments.
- `429`: Rate limited by Adako or by the ad platform. See Retry-After.
- `500`: Unexpected error inside Adako.
- `502`: The ad platform returned an error.

---

[API](https://skmtc.dev/adako/apis/adako-rest-api.md) · [All operations](https://skmtc.dev/adako/apis/adako-rest-api/llms.txt) · [OpenAPI document](https://skmtc.dev/adako/apis/adako-rest-api/revisions/59ee60d48a56?raw)