Pipedrive attribution, driven by won deals

A rep renames a stage, and your attribution tool goes quiet. On Pipedrive, that cannot happen.

Pipedrive attribution works on three things Pipedrive never shows a rep: the deal's status enum, the numeric stage_id behind every stage name, and the 40-character hash key behind every custom field. Attribi reads the first, asks you for the second, and stores the third at setup. That is why renamed stages and extra pipelines cannot break it.

This is the under-the-hood half of the Pipedrive page. For the Google half of the upload, read Pipedrive Marks the Deal Won. Nobody Tells Google Ads. alongside it.

How does Pipedrive attribution map onto Person, Deal and Organization?

Pipedrive attribution is the practice of tying a Pipedrive deal's outcome back to the ad click that produced its person, and it rests on three objects. A Person holds emails and phones lists, one of each flagged primary. A Deal carries its own value and currency, sits at one stage_id inside one pipeline_id, has a status of open, won or lost, and gets a won_time when won. An Organization is the company. Pipedrive's help says a deal "must be linked to a person, organization or project".

Attribi writes to two of the three. One provisioning pass creates the same sixteen custom fields on the Person (/v1/personFields) and the Deal (/v1/dealFields), and later writes fourteen. Nothing touches the Organization.

Every field exists on both objects. Type names are Pipedrive's own, from its custom field types article.

Two type details. Pipedrive's v2 API validates a Date field strictly, so mta_first_touch_at is cut to ten characters. And the four Large text fields were first created as Autocomplete, which Pipedrive caps at 255 characters; connections made since 21 September 2026 get Large text, older ones keep 255-character columns and get the attribution path clipped in the middle.

Why do Pipedrive custom fields have hash keys, and why does that matter?

Create a field called "MTA Click ID" and Pipedrive does not give you an API key called mta_clickid. It gives you something like dcf558aac1ae4e8c4f849ba5e668430d8df9be12. Pipedrive's developer docs describe custom field keys as randomly generated 40-character hashes that differ for every account. The label is for humans; every API read and write uses the hash, and in v2 the hashes sit inside a custom_fields object.

Attribi deals with this once. Provision fields lists the existing fields on each object, matches by display name, creates whatever is missing, and stores two maps in your connection, mta_person_field_keys and mta_deal_field_keys, from our canonical name to your account's hash. Every push re-keys the fourteen values through them. Re-provisioning is safe because matching is by name, which also means a renamed field is recreated. Leave the labels alone.

If you build your own bridge, this is what people get wrong. A script that writes mta_clickid as a literal key is silently ignored, and because the hash is per account, nothing copied from a tutorial works in yours. Pipedrive's Data fields page has "Copy API key" in the "..." menu beside each field. Use it.

How does Attribi decide a Pipedrive deal is won?

It asks Pipedrive. The revenue pull calls GET /api/v2/deals?status=won, with updated_since set to the last successful run and updated_until to the moment this run started, sorted by update_time descending, walking the opaque cursor Pipedrive returns. All four parameters are on Pipedrive's Deals reference, verified 12 October 2026. Then, per deal, it re-checks deal.status === 'won'.

status is Pipedrive's own enum, not a stage. A deal in a pipeline that ends in "Contract signed" and one in a pipeline that ends in "Deposit paid" both have status: won the moment a rep marks them Won. Pipedrive's multiple pipelines article says each pipeline "has its own set of stages", so a rule keyed on a stage name must be rebuilt per pipeline; a rule on status never is. That is why this page can say "rename anything you like", a promise the Zoho page cannot make, because Zoho's pull matches a stage name.

Three rules sit on top:

• Value comes from the deal, or there is no upload. A won deal with no value, or zero, is mirrored in Attribi but sends nothing.
• Currency comes from the deal and is never guessed. Pipedrive lets an account define custom currencies. If the code is not a standard ISO 4217 code, USDT for instance, Attribi withholds the closed-won upload, holds its cursor so the deal is seen again, and reports why. Nothing falls back to US dollars.
• A deal fires once. Attribi reads the matched lead's closed_won_at first, so a deal edited after winning is seen again and skipped.

Each pass reads up to 50 pages of 100 deals; a capped run holds its cursor so the unread tail is picked up next time. The pull runs daily, not when a card is dragged.

Where do the qualified stage IDs come from?

Won needs no configuration. Qualified does, and this is the first number that bites.

Pipedrive identifies a stage by an integer. The deal carries stage_id, not a name, unique across your account even when two pipelines both have a "Proposal sent". The qualified pass is a second query, GET /api/v2/deals?status=open, over the same window, keeping only deals whose stage_id is in your list. An empty list skips the pass, so until you fill it you get closed-won conversions only, with no warning in either product.

Finding the IDs is the fiddly part. Pipedrive's pipeline editor (Deals tab, then the pencil icon beside the pipeline dropdown) shows names, probabilities and rotting settings, and no IDs. Two ways work:

1. Call GET /api/v2/stages with a personal API token from Settings, Personal preferences, API. Each entry has id, name and pipeline_id.
2. Ask Pipedrive support for a list of your stages and their IDs.

Paste the IDs, comma separated, into the connection in Attribi. Renaming a stage keeps its ID. Deleting one and recreating it elsewhere gives it a new ID, and that is the event worth a re-check.

What changed in the API v2 migration?

Pipedrive's changelog announced on 14 April 2025 that most v1 endpoints for deals, persons, organizations, pipelines and stages were deprecated, effective 1 January 2026. Attribi moved to v2 in September 2026. Per the migration guide: persons go through /api/v2/persons with emails and phones as arrays of objects and custom fields under custom_fields; deals use /api/v2/deals with cursor pagination and RFC 3339 timestamps. /v1/personFields and /v1/dealFields are not in the deprecation list, so provisioning still uses them.

One honest limit. No customer had a live Pipedrive connection when the migration shipped, so v2 is covered by contract tests against Pipedrive's documented shapes, not a production tenant. The first real connection gets a live smoke: a pushed test lead, then a revenue pull checked for matching and cursor movement.

What were the deal-fields and unwritten-fields gaps, and what is left?

Two defects lived here until 21 September 2026. Both are fixed; their residue shapes what you will see.

G41, the deal-fields gap. Provisioning created all sixteen fields on the Deal from the start, and for months nothing wrote them. Now, after each person update, Attribi lists that person's open deals (/api/v2/deals?person_id=...&status=open, newest first, up to ten) and writes the same fourteen values to each by deal hash key. Open only, on purpose: a deal won in January under a Google journey must not be rewritten to September's Facebook one. What is left: this runs when a lead converts, so a deal opened later stays empty until the person converts again.

G40, the unwritten-fields gap. The push used to send a twelve-name bag, five of which (mta_click_id, mta_last_touch_at, mta_days_to_conversion, mta_attribution_linear, mta_attribution_data_driven) were legacy names the provisioner had stopped creating. They were dropped silently, and only seven of sixteen fields ever filled. The bag is now built in one shared module that a drift test pins to the provisioner's list. The two never written are mta_clickid and mta_clickid_type: your form fills them, and a push that wrote them, even as null, would clobber your value.

Other limits, stated once:

• Pipedrive's usage limits page (updated 3 September 2026) caps custom fields per company at 30 on Lite, 100 on Growth, 300 on Premium and 500 on Ultimate. Attribi creates 32. The page does not say whether the count spans item types, so on Lite check Settings, Company, Usage before provisioning. Guides that tell you to look for a "Professional" plan are out of date: Pipedrive renamed its plans to Lite, Growth, Premium and Ultimate in 2025.
• Web Forms are part of the LeadBooster add-on. Pipedrive's product updates list an August 2026 release that captures UTM parameters and cookie values into hidden fields; the Web Forms help article, checked 12 October 2026, does not describe it, and a click ID is not a UTM parameter. Test with a real ?gclid= link.
• A person who first appears through the pull gets their lead-stage event on the day the pull creates them, not the moment they filled the form, with one synthetic touch rather than a journey. Without the Attribi script there is no multi-touch path to write back.
• A phone without a country code cannot match on Meta. Collect phones in international format.

What does the Pipedrive side of setup look like, screen by screen?

1. Connect. From Attribi's Connections page choose Pipedrive, full mode or attribution only, and approve Pipedrive's OAuth consent screen. Pipedrive returns an api_domain such as https://yourcompany.pipedrive.com, and every later request goes there.
2. Provision fields. Click Provision fields in Attribi. Then in Pipedrive open the account menu, Personal preferences, Data fields, and check the Person list and the Deal list for sixteen fields prefixed MTA on each.
3. Collect the stage IDs. Call GET /api/v2/stages as above, or ask support, and paste the qualified IDs into the connection. Only users with deal admin permissions can edit pipelines, so that is the person to ask.
4. Push a test lead. Click Push latest lead. Open the matching Person in Pipedrive and check the MTA fields, then one of that person's open deals for the same fourteen.
5. Watch the first pull. After the next daily run, open a deal won in the window and confirm the lead in Attribi shows the value, the currency, and an upload status per connected ad platform.

Nothing here needs LeadBooster or a plan above Lite, apart from the custom field cap.

A worked example, from a won deal to a Google Ads upload

The numbers are illustrative. Priya clicks a Google ad on 2 September 2026 and lands on /pricing with ?gclid= in the URL. Attribi's script records the click ID against her visitor, or, with no script, your form writes it into MTA Click ID with MTA Click ID Type set to gclid. She books a demo; a Person is created, and a Deal titled "Acme rollout" opens at 18,500 EUR.

On 30 September a rep marks it Won. Pipedrive sets status: won, won_time: 2026-09-30T14:12:00Z, and bumps update_time.

Overnight, pass one returns "Acme rollout" with person_id: 918. Attribi reads /api/v2/persons/918, takes the primary email and phone, and reads the two click-ID hash keys from custom_fields. It matches, or creates, the lead by email, then phone, with gclid attached. closed_won_at is empty, the value is 18,500, EUR is a standard code, so the closed-won fan-out fires.

On Google's side the event carries the click ID, the SHA-256 of the normalised email and phone, conversionValue: 18500, currencyCode: EUR, the won time, and a transaction ID of the lead's ID plus closed_won, so a re-run cannot count it twice. The click is 28 days old: inside Google's 90-day import limit, and inside the 30-day click window Attribi's self-created conversion actions use today; a day-40 win would need that window raised. The maths are in Your Sales Cycle Is Longer Than Google's Memory.

The next night a rep adds a note and the deal reappears in pass one. closed_won_at is set, so nothing fires.

Common questions about this connection

Does Attribi write anything on the Pipedrive Organization? No. The sixteen fields are created on the Person and the Deal only, and the fourteen values are written to the Person and its open deals. An Organization receives nothing from Attribi, and the pull never reads one.

What happens to a Pipedrive deal in a custom currency such as USDT? The closed-won upload is withheld and the deal is held for the next run, because ad platforms accept only standard three-letter currency codes. Attribi reports the deal and the reason on the connection. A qualified event for the same deal still fires, without a value.

How many Pipedrive deals can one revenue pull read? Up to fifty pages of one hundred deals per pass, five thousand for won and five thousand for qualified. A capped run holds its cursor so the unread deals are seen next time; after several consecutive capped runs it advances anyway, so a very large account never stalls forever.

Do the deal-level MTA fields fill for a deal opened after the person converted? Not until that person converts again. The deal pass runs when a lead is pushed and copies the fourteen values to the person's open deals at that moment. A deal opened later starts empty, and won deals are never rewritten.

How many of Pipedrive's custom fields does Attribi use? Thirty-two, sixteen on the Person and sixteen on the Deal. Pipedrive caps custom fields per company at 30 on Lite and 100 on Growth, and does not say whether the cap spans item types, so a Lite account should check Settings, Company, Usage before provisioning.

The takeaway

Pipedrive is the friendliest CRM in Attribi's set because the things attribution depends on are structural: a won deal is status: won whatever you called the stage, a stage is an integer whatever you rename it to, and a custom field is a hash whatever its label says. The cost is two numbers, the stage IDs and the custom field count, to look up before the first pull. CRM connections start on the Growth plan at 99 dollars a month, and every new workspace gets 30 days on Pro with no card, long enough to watch your first won deals reach your ad platforms.