Export attribution to Google Sheets, one row per lead

When you export attribution to Google Sheets with Attribi, the sheet becomes a pipeline, not a report. Every website conversion appends one 50-column row to the tab you picked. You change the Status cell and type a deal value and currency. Once a day Attribi reads those four cells back and uploads the stage to your ad platforms.

The setup steps above say what the connection does. This is what they leave out. Google's own route, a sheet feeding Google Ads through Data Manager, is a different article: Offline Conversions from a Google Sheet.

What is Attribi's attribution export to Google Sheets?

Attribi's attribution export to Google Sheets is one appended row per website conversion, 50 columns wide: six lead cells, five touches of eight fields each, and four stage-tracker cells that Attribi reads back once a day. The row is written once, by position, and the only cells that ever change are the ones a person edits.

The row is built in lib/sheets-row.ts; the headings live in lib/sheets-columns.ts. On a tab Attribi set up from empty, row 1 reads like this.

The first 46 cells are written by position, not by heading: the email lands in column C because it is the third cell in Attribi's row. Insert a column between A and AT and every later export lands one column off your headings, and nothing errors. That is why the setup step says a dedicated tab. The last four are the opposite. Before every append Attribi reads row 1 and finds the four stage headings by name, case-insensitive, at or after column AU, so a column inserted before AU moves nothing. The floor at AU exists because a customer's own column called Status inside A to AT was once adopted as the stage column and overwrote a phone number with the word Lead.

Click ID Platform uses Attribi's vocabulary (google, google_wbraid, google_gbraid, meta, tiktok, microsoft, linkedin, snapchat, dv360, twitter), so a pivot on it says which platform's click produced each lead.

Why is the row written once and never updated?

The only writer of rows is /api/convert. It builds the 46-cell row, inserts the lead, and hands both to lib/sheets-append-retry.ts. Marking a lead qualified or closed won inside Attribi does not touch the sheet. A repeat submission from the same visitor within 30 minutes is folded into the existing lead and appends nothing, because the tracker fires on email blur and again on submit.

On a tab enrolled in stage tracking the append uses the Sheets API appendCells request, which takes the tab's numeric id and always writes after the last data row from column A. The older values.append locates a table by heuristic, and on a tab mixing 46-column and 50-column rows it once landed a whole row shifted right, with the lead id at AV. Tabs connected before stage tracking existed, and never re-saved, still use it.

If Google answers with a transient error, Attribi holds the export and queues a retry rather than writing a row it could not verify. The retry scans the Attribi Lead ID column first, so a lost response never produces two rows. Non-enrolled tabs have no id to check, so a transient failure drops the row, as before.

An enrolled append is three API requests: resolve the tab, read row 1, append. Google's Sheets API usage limits, verified 2026-10-12, are 300 read and 300 write requests per minute per project, 60 of each per minute per user per project, no daily cap, and a 429 when exceeded. That is roughly twenty conversions a minute through one connection before a burst is held and retried.

What does the daily read-back check before it acts on a row?

The pull is lib/sheets-pull.ts. It runs on the daily revenue-pull schedule, the same cadence as the CRM pulls, for every site whose Save & Connect wrote stage_tracker_ready. There is no cursor; every run is a full scan.

1. Read row 1 and resolve the four headings. If one is missing or sits inside A to AT, the run records the re-save health message and stops. Leads still export.
2. Read four single-column ranges, rows 2 to 5,001, with valueRenderOption: UNFORMATTED_VALUE. Email and phone are never requested. Unformatted matters: a currency-formatted Deal Value would otherwise arrive as AED 1,250.50 and fail to parse.
3. Keep rows with a non-blank id and a recognised Status. Exact words after trim and case folding: lead, qualified, closed won. The dropdown is created with strict: false, so Sheets lets you type Won with a warning, but the pull treats that row as blank.
4. Drop ids that are not UUID-shaped before touching the database. One bad value inside an id=in.(...) filter used to fail the whole 200-id chunk and hide every genuine lead in it.
5. Compare sheet stage to Attribi's stage. Only forward moves count, so Closed Won to Lead and back fires nothing twice.
6. For Closed Won, require both cells. A blank Deal Value counts as valueSkipped, a Currency that is not three letters as currencySkipped. The lead still gets qualified if it was not. The close waits.
7. Fire at most 200 transitions through the same markLeadQualified and markLeadClosedWon functions a CRM pull calls. Skips never consume the budget, and the attempt window advances a full batch each day, so a thousand waiting candidates clear in five runs even if some fail every time.
8. Hold the close when the qualify fails. A Lead to Closed Won jump is two calls; if the first fails, the close is held rather than written with qualified_at null. Tomorrow retries both.

What does a Closed Won row need, exactly?

A number and a code. The parser in lib/sheets-columns.ts is more forgiving than that sounds.

The dot-only case 1.250 reads as 1.25, because without a locale a thousands dot cannot be told from a decimal point. Type 1250 and it never comes up.

Currency is required rather than defaulted on purpose. The shared close function coerces a blank currency to USD and every platform upload sends the stored currency, so an AED deal with a blank cell would reach Google Ads and Meta as a USD deal of the same number. There is no site-level default currency yet. Editing Deal Value after the close has been read changes nothing.

Which spreadsheets can Attribi see in your Drive?

One file per connection, because you chose it. The OAuth request in app/api/oauth/google-sheets/init/route.ts asks for a single scope, drive.file, which Google's Drive scopes page (verified 2026-10-12) lists as non-sensitive and describes as access to Drive files you open with the app. Nothing about the rest of your Drive is granted.

The grant for a particular file is issued by the Google Picker when you select it, and only if the Picker was built with setAppId, which Google's PickerBuilder reference describes as the id of the application needing to access the user's files. From 2026-04-16, when the Picker replaced a broader Drive scope, until 2026-08-26, our Picker was built without that call. Every pick looked successful and every tabs fetch then returned 404, because no grant existed; no customer completed a connection through the Picker in those four months. Recorded as G60, the app id is now derived server-side from the OAuth client id and pinned by a test.

Two consequences of the per-file scope. A file picked under one Google account cannot be reached by re-consenting with another; pushes fail with the re-pick message and nothing is written anywhere. And deleting the spreadsheet, or revoking the app in your Google account, returns 403 or 404 on the next append; reconnecting OAuth does not fix it, picking the file again does.

What does the health badge on the Google Sheets card mean?

The card shows one of three badges from lib/integration-health.ts. Only lasting failures move it; a 429 or a 5xx is logged and retried, never written to the ledger.

The stored message takes one of three shapes:

• "The selected spreadsheet may have been deleted or Attribi's access revoked", ending "re-pick it from the Google Sheets card". Written on 403 or 404. Use Reconfigure and pick the file again; a re-save clears the counter immediately.
• "Stage-tracker columns (Attribi Lead ID / Status / Deal Value / Currency) are missing or were moved into the lead-export area", ending with "re-save". Written by the append and the daily pull when row 1 no longer resolves. Leads still export. Save & Connect adds only the missing headings, after your last used heading and never before AU.
• "HTTP 401:" followed by Google's text. The token was rejected and could not be refreshed. Go through the Google consent again; since 2026-10-05 a reconnect keeps the picked file and the enrolment.

What the badge never shows: skipped Closed Won rows, non-UUID ids, ids from another workspace, and transitions deferred past the 200 cap. Those are counted in the job result and written to the server log as one warning line per run. There is no card signal for any of them today.

What does a month in the sheet look like for a small team?

The numbers are illustrative. Picture a three-person studio on Google Ads and Meta, no CRM, a tab called Pipeline.

Week one, 11 rows arrive at Status Lead. The office manager adds a Notes column at AY, which is fine because it sits after AX.

Week two, she changes four rows to Qualified. The next morning's pull fires four qualified events to both ad accounts. A fifth row she set to Qualified was pasted in from a form email; it has no Attribi Lead ID and is ignored.

Week three, the first deal closes: Status Closed Won, Deal Value 18,500, Currency aed. The pull reads 18500 and AED and uploads the close. A second close the same day has the currency blank. It is counted as currencySkipped, the lead is marked qualified, and the close waits. Nothing on the card says so. She notices a week later when Meta's purchase count is one short, types AED, and the next run sends it.

Week four, 38 rows: 9 Qualified, 3 Closed Won with values, 1 still blank. The tab is 38 rows into a 5,000-row scan and about 1,900 cells into Google's stated ceiling of 20 million cells per spreadsheet, verified 2026-10-12. If a page tells you that limit is 10 million, it is out of date.

When should the sheet hand over to a CRM?

Not when it fills up. At 40 leads a month the 5,000-row scan lasts ten years, and an archive tab resets it. The signals are about people and sources.

Hand over when leads arrive from somewhere other than the website. The sheet cannot create a lead from a row you type, so phone enquiries never reach the ad platforms through it. A CRM pull can bring those in, and since 2026-08-10 it fires the lead stage for them as well as qualified and closed won. Hand over when two people need to own one lead, or when you need a stage between Qualified and Closed Won. Do not hand over for latency alone: the pull is daily, and so is every CRM pull.

The Sheets connection itself is ungated on every plan. Uploading the stage to one ad platform starts on Starter at 49 dollars; a CRM connection starts on Growth at 99 dollars. The sheet keeps working beside a CRM.

What the Sheets connection does not do

• Create leads. A row without a UUID in Attribi Lead ID is inert, typed, pasted or imported.
• Sync in real time. Up to 24 hours between a Status edit and the upload, longer if more than 200 leads are waiting.
• Surface skipped rows in the interface. They appear only in job counts and the server log.
• Write stages back. A lead closed inside Attribi or by a CRM pull is not reflected in the sheet, and leads Attribi found elsewhere never get a row.
• Carry the whole journey. Five touches of eight fields; the count is the only trace of the rest.
• Survive a renamed tab. Attribi resolves the tab by title on every write, so rows stop landing until you Reconfigure and pick it again.

Common questions about this connection

Can I sort, filter or add my own columns to the connected tab? Sort and filter freely; the read-back matches rows by Attribi Lead ID, not position. Add your own columns after AX. Never insert a column inside A to AT, because the 46 export cells are written by position.

What happens if I type a Status that is not in the dropdown? Sheets accepts it with a warning because the rule is not strict. Attribi does not: the pull recognises exactly Lead, Qualified and Closed Won, case-insensitive, and treats anything else as blank.

Why did my Closed Won row upload as a qualified lead and not a close? Deal Value or Currency was blank or unreadable. The pull still fires the qualified stage, skips the close, and counts the skip in the job result. Fill both cells and the close goes on the next run.

What if I connected before September 2026 and the tab has 46 columns? It keeps exporting 46-cell rows until you open Connections and Save & Connect again, which adds the four headings and the dropdown. If row 1 of that older tab holds a lead rather than headings, insert a blank row above it first.

The takeaway

A sheet works as a pipeline when the software is strict about what it reads and honest about what it ignores. Attribi reads four cells per row, acts only on forward moves with a value and a currency, and tells you in the logs rather than the interface when it skipped one. Every new workspace starts with 30 days on the Pro plan, no card required, which is enough to run a month of leads through a sheet and watch the stages reach your ad accounts.