Daily ad performance, with honest attribution

---
name: "Daily Ad Performance and Attribution Report"
description: "Refresh a daily ad report with four-week trends, morning reporting windows, and clearly separated attribution signals."
connection_needs:
  - "Meta Ads: read ad-set performance, account timezone, pixel events, and activity logs."
  - "Amplitude: read demo-page event totals, campaign tags, creative codes, and timestamped buckets."
inputs:
  - "report_artifact: existing destination Markdown artifact selected during setup"
  - "report_title: title and top-level heading of the destination report"
  - "destination_space: space containing the report"
  - "report_space_name: display name of that space"
  - "meta_connection: selected Meta Ads connection"
  - "meta_connection_account: selected account on that connection"
  - "meta_ad_account: accessible advertising account ID"
  - "meta_account_name: display name of the selected advertising account"
  - "meta_dataset: accessible pixel/dataset ID"
  - "meta_dataset_name: display name of the selected pixel"
  - "amplitude_connection: selected Amplitude connection"
  - "amplitude_connection_account: selected account exposing the reporting project"
  - "campaign_tag: exact Meta campaign UTM value used to qualify demo-page events"
  - "separate_vertical: vertical that must remain a separate report grouping"
---

# Daily Ad Performance and Attribution Report

## Purpose

Maintain an existing marketing report with four complete weekly performance periods and a separate morning-to-morning daily view. Reconcile ad-platform, pixel, and website-analytics signals without presenting page views or sitewide events as confirmed bookings. Preserve older report entries and user edits.

## Setup

Supply these installation bindings; none inherits an account, client, destination, or campaign value from the original workspace.

| Binding | Meaning and source |
| --- | --- |
| `{{input:report_artifact}}` | Select an existing Markdown report with read/edit access. |
| `{{input:report_title}}` | Supply its title; the insertion anchor is `# {{input:report_title}}`. |
| `{{input:destination_space}}` | Select the destination report's space. |
| `{{input:report_space_name}}` | Resolve that space's display name. |
| `{{input:meta_connection}}` | Select the Meta Ads connection with reporting access. |
| `{{input:meta_connection_account}}` | Select its integration account. |
| `{{input:meta_ad_account}}` | Select the advertising account to query. |
| `{{input:meta_account_name}}` | Resolve that advertising account's display name. |
| `{{input:meta_dataset}}` | Select the pixel/dataset to inspect. |
| `{{input:meta_dataset_name}}` | Resolve that pixel's display name. |
| `{{input:amplitude_connection}}` | Select the Amplitude connection. |
| `{{input:amplitude_connection_account}}` | Select the account/project containing the required web events. |
| `{{input:campaign_tag}}` | Supply the exact `utm_campaign` value qualifying Meta-tagged events. |
| `{{input:separate_vertical}}` | Supply the vertical label to report separately when aggregating ad sets. |

Required event/schema assumptions: Amplitude `[Amplitude] Page Viewed`, `[Amplitude] Page Path`, and `[Amplitude] Page Location`; the exact path `/demo`; URL parameters `utm_campaign` and `creative_code`; pixel events `DemoBookerViewed` and `Schedule`. These are behavioral dependencies, not evidence that another project has the same tracking.

Discover available ad platforms, new campaigns, creative-to-ad/vertical mappings, accessible accounts, and source timezone/window support on each run. Do not freeze the current discovery results into this template. The existing source uses Meta Ads and Amplitude; additional platform coverage depends on actual access at execution time.

## Triggers and execution

Agent-only automation, scheduled every day at **06:00 America/Los_Angeles**, all seven days. The reporting date is the current date in that timezone.

No code execution or agent/code handoff is configured in the source. No explicit model, custom retry policy, or run configuration is saved. Creating this template does not run or enable an automation.

The weekly view covers four complete consecutive seven-day calendar periods ending the day before the reporting date. The daily view covers **05:00 PT on the previous day through 05:00 PT on the reporting date**. Use the named timezone to resolve calendar boundaries; do not replace them with fixed UTC offsets.

## Workflow

1. Read the live destination report. Locate its top-level heading and current reporting-date section.
2. Resolve authenticated, queryable ad-platform access for this run. Record missing access without waiting for sign-in.
3. Query the four weekly periods and the separate daily window. Label each source's actual window. Calendar-day-only data must not be labelled as the requested 05:00–05:00 window.
4. For the selected Meta account, query each weekly block and aggregate ad sets by vertical, retaining the configured separate vertical. Compute **CTR = clicks / impressions** and **CPC = spend / clicks**.
5. Read pixel `DemoBookerViewed` and `Schedule` event counts. Keep sitewide totals separate from ad and vertical rows unless a verified attribution exists; never put a sitewide Schedule event in an ad or vertical row.
6. Read Amplitude event totals, not unique users, for `[Amplitude] Page Viewed` where `[Amplitude] Page Path` equals exactly `/demo`. Meta-tagged views additionally require `utm_campaign={{input:campaign_tag}}` and a verified `creative_code` mapping from `[Amplitude] Page Location` to the ad and vertical. A `vertical` parameter or `fbclid` alone is insufficient. Inspect new campaigns and creative codes each run.
7. Verify the Amplitude project's timezone before assigning events to PT windows. If unverified, label source-date buckets separately and show exact-PT ad-tagged DemosViewed as unavailable. Do not silently fall back to another analytics source.
8. Reconcile weekly and daily values by source and exact window. Keep Amplitude page-view fires, pixel fires, and Ads Manager Schedule results separate. Use “confirmed demos booked” only with independent CRM/calendar booking confirmation. Otherwise use “Meta-attributed Schedule” and explain its limits. Disagreements must be stated without asserting unsupported attribution.
9. Insert one dated section immediately below the report title and above previous dates, or refresh the existing section for that date. Preserve older entries and user edits. Include four-week and daily tables, source/window caveats, ad-level tagged views, sitewide pixel counts, and access limitations.
10. Read the artifact after editing to verify the saved section. Finish with a concise status naming included and unavailable platforms and the artifact update.

## State and failure behavior

The report artifact is the durable output and the reporting-date section is the duplicate check. Re-running the same date refreshes that section; this is not a transactional or exactly-once guarantee. The source also retains operational notes in a scratchpad; generalized relevant notes appear below. Historical report metrics and previous visualization values are not template state.

Missing access, unavailable metrics, or unverifiable vertical attribution are shown as **—**, with the reason. They are not zero. Do not reuse historical numbers as current data or wait for sign-in to complete the report.

If Ads Manager returns “Not available,” show — for its attributed Schedule metric even if the sitewide pixel recorded Schedule events. Keep the latter in the sitewide section. If timezone verification fails, retain separately labelled source-date data without claiming exact PT alignment.

The saved source specifies no custom retry/backoff, checkpoint, concurrency lock, rollback, or separate failure-notification channel. Preserve its read-before/edit/read-after sequence without claiming those guarantees.

## Integration data and capabilities

| Integration actually used | Data and capabilities consumed | Relevant semantics |
| --- | --- | --- |
| Meta Ads | Read selected account metadata/timezone; ad-set names, spend, impressions, clicks, results; hourly advertiser-timezone breakdowns; dataset event stats; account activity logs for new ads and status/budget changes. | Ad-set aggregation uses current vertical mappings. `time_range` is a JSON string. Pixel fires are sitewide; Ads Manager Schedule results are attribution signals. Dataset stats have a recorded 28-day lookback. No ad, budget, or campaign writes are part of this automation. |
| Amplitude | Read project timezone and event segmentation for `[Amplitude] Page Viewed`; filter exact `[Amplitude] Page Path`; inspect campaign/creative tags in `[Amplitude] Page Location`; use event totals and hourly source timestamps. | Page-view fires are not unique visitors or bookings. Hourly segmentation uses `i=-3600000`; the recorded implementation uses 7–8-day chunks and output-file mode because a four-week hourly query was rejected. A sparse filtered series cannot establish timezone. |

Type's document capabilities read and edit only the configured report, then read it back. No messaging integration is required by the source. Booking confirmation is a conditional evidence requirement; this template does not claim a configured CRM/calendar integration or prescribe an unused provider.

## Reference implementation

Agent instructions below preserve the source's reporting decisions. Assumptions: the selected connections expose the event schema and reporting operations described above; setup placeholders have been resolved; the report exists. The generic layout below replaces the dependency on an original dated report.

**Reuse when these assumptions hold; adapt when they do not, preserving the behavior above.**

```text
Every day at 6:00 AM America/Los_Angeles, update the existing Markdown artifact "{{input:report_title}}" (artifactId {{input:report_artifact}}) in {{input:report_space_name}} (spaceId {{input:destination_space}}). The reporting date is the current date in America/Los_Angeles.

Read the live artifact first. Add exactly one new dated section immediately under "# {{input:report_title}}", above prior dates; if the current date already has a section, refresh that section instead of duplicating it. Preserve all older entries and user edits. Read the artifact again after editing to verify the saved section.

Follow the generic report structure supplied below:
1. A four-week trend table by platform, seven-day period, and vertical, with spend, impressions, CTR, CPC, DemosViewed, and Demos booked. Use four complete seven-day calendar periods ending the day before the reporting date, Pacific time. Include all ad platforms that are authenticated and queryable at run time (Meta and any other connected ad platform). Use each platform's actual source window and label differences; never invent a cross-platform total when definitions or windows differ.
2. A separate last-24-hours table by platform and vertical for 5:00 AM PT on the previous day through 5:00 AM PT on the reporting date. If a platform only supports calendar-day reports, label its actual window; do not present it as the 5 AM–5 AM window.

For Meta, use the {{input:meta_account_name}} account (ad account ID {{input:meta_ad_account}}) and {{input:meta_dataset_name}} (dataset ID {{input:meta_dataset}}) if still accessible. The ad entity tool accepts a JSON string in time_range, for example {"since":"YYYY-MM-DD","until":"YYYY-MM-DD"}; query each seven-day block and aggregate ad sets by vertical, including {{input:separate_vertical}} separately. CTR = clicks / impressions; CPC = spend / clicks. Query pixel event stats for DemoBookerViewed and Schedule. DemoBookerViewed counts pixel event fires across the site, not unique people or necessarily Meta-attributed traffic; show sitewide totals separately unless a verified vertical attribution exists. Meta-attributed Schedule results are signals, not independently confirmed customer bookings. Distinguish them from sitewide pixel Schedule events.

For DemosViewed web analytics, use the connected Amplitude project. Query `[Amplitude] Page Viewed` where `[Amplitude] Page Path` equals the top-level demo booking page path (one leading slash followed by demo, with no suffix), using event totals rather than unique users. For Meta ad-tagged views, require `utm_campaign={{input:campaign_tag}}` and map `creative_code` in `[Amplitude] Page Location` to the ad and vertical; do not infer attribution merely from a `vertical` page parameter or an `fbclid`. Inspect new campaigns and creative codes at each run. Confirm the Amplitude project's timezone before placing counts in PT weekly or 5 AM–5 AM windows; if it cannot be verified, label Amplitude's source-date buckets separately and mark exact PT ad-tagged DemosViewed unavailable. Do not silently substitute a different web-analytics source. Keep Amplitude page-view fires, {{input:meta_dataset_name}} `DemoBookerViewed` fires, and Ads Manager `Schedule` results separate; none proves a completed booking. For other connected platforms, only report Amplitude ad-tagged views after verifying campaign-to-platform and vertical mapping.

For other connected platforms, use connected integrations or authenticated browser access only when actually available. If access is absent or a metric cannot be obtained or attributed to a vertical, mark it unavailable (—) and state why; never treat unavailable as zero. Do not wait for sign-in to finish the report. Do not silently reuse old numbers as current data.

Finish with a concise status indicating which platforms were included, which were unavailable, and that the artifact was updated.

Booking reconciliation rule: Never put a sitewide {{input:meta_dataset_name}} Schedule event into an ad or vertical row. If Ads Manager returns "Not available" for that date or window, show — for Meta-attributed Schedule even when the pixel recorded an event; show the pixel count separately as sitewide. An Amplitude demo-page view is not a booked demo. Use "confirmed demos booked" only when a CRM or calendar source independently confirms completion of the booking; otherwise label the metric "Meta-attributed Schedule" and explain the limit. Reconcile weekly and 24-hour reports by source and exact time window before publishing; if values disagree, do not assert attribution and state the discrepancy.
```

### Operational notes retained from the source

- Read the selected ad account's timezone. Calendar-date `time_range` queries use advertiser time. For exact PT windows, query single days with `breakdowns: ["hourly_stats_aggregated_by_advertiser_time_zone"]` and select/rebucket actual timestamped hours. In the source's America/New_York account, ET hours 00–02 belonged to the preceding PT day; this is conditional on that timezone, not a default for the new account.
- The recorded `ads_get_ad_entities` call used `ad_account_id`, `level: "adset"`, `fields: ["name", "amount_spent", "impressions", "clicks", "results"]`, JSON-string `time_range`, `breakdowns`, and `client_conversation_id`. Schema discovery for this operation was unavailable in the original run; verify the current tool contract instead of treating that limitation as permanent.
- `ads_get_dataset_stats` returned timestamped hourly buckets with PT offsets and a 28-day lookback. Check returned offsets and coverage; do not present a truncated lookback as a full requested period.
- Use Amplitude hourly segmentation in 7–8-day chunks with output-file mode. Verify the selected project's timezone with an unfiltered `_active` hourly query for today when needed; the filtered `/demo` series may be too sparse. Do not assume the original project's timezone.
- `ads_account_get_activity_logs` with `ad_account_id` and ISO `start_time` helps discover new ads and status/budget changes between runs.

### Report structure

Use the report's existing formatting and preserve user edits. The source's report layout has these components; placeholders below are structural, not historical values.

```markdown
## [Reporting date] — Daily ad report

### Four-week trend by vertical
Period: [four complete weekly ranges, requested timezone, each source's actual window]

| Platform | Week | Vertical | Spend | Impressions | CTR | CPC | DemosViewed | Meta-attributed Schedule |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [source] | [period] | [verified group] | [value] | [value] | [value] | [value] | [value or —] | [value or —] |

[Metric definitions, access limits, attribution caveats and source-window differences.
Only use “confirmed demos booked” when independently confirmed.]

### Last 24 hours by vertical
Requested window: [previous-day 05:00 PT through reporting-day 05:00 PT]
Actual source windows: [source-specific windows and differences]

[Separate table by platform and vertical with the same metric definitions.]

### Ad-level tagged demo-page views (Amplitude)
[Creative code, mapped ad/vertical, weekly event counts, four-week total;
separately label source-date buckets when PT alignment cannot be verified.]

### Other platforms, last 24 hours
[Available data or — with reason. No cross-platform totals across incompatible definitions/windows.]

### Sitewide pixel events
[DemoBookerViewed and Schedule counts, actual coverage and timestamp window.
Keep sitewide Schedule separate from ad/vertical attribution.]

### Status
[Included sources, unavailable sources, reconciliation discrepancies.]
```

## Verification

**Sanitized examples derived from explicit source rules (not executed tests):**

- Ads Manager says “Not available” while a pixel Schedule event exists: the attributed row remains —; the pixel event is reported separately as sitewide.
- A demo-page URL has only a `vertical` parameter or `fbclid`: do not count it as a verified Meta-tagged view.
- An Amplitude page view is present without independent booking evidence: it is a page-view event, not a confirmed booking.
- The current reporting date already exists: refresh that section instead of adding a second one, preserving older entries and user edits.

**Proposed acceptance checks for a reconstructed automation:**

1. Use controlled source responses covering all four weekly periods and the daily window; compare groupings, clicks/impressions CTR and spend/clicks CPC against the inputs.
2. Exercise account/project timezone differences and a daylight-saving boundary; verify calendar and 05:00 boundaries, actual-source labels, and hourly rebucketing.
3. Make project timezone unverifiable, an ad platform inaccessible, or a metric unavailable; verify — with reasons, no invented zeros, no stale reuse, and no waiting for sign-in.
4. Supply contradictory sitewide and attributed Schedule values; verify source separation and discrepancy reporting.
5. Run twice for the same reporting date against a test report containing older entries and manual edits; verify a single current-date section and preserved history.
6. Change creative mappings, add a campaign, and change authenticated platform access between runs; verify rediscovery rather than reuse of the earlier snapshot.
7. Verify the saved report with a fresh read after editing. Separately test edit/read failures before claiming any recovery guarantees.