Attribution in a CRM is not a feature you switch on. It is the sum of the fields that a lead or a deal carries by the time it is won: if the campaign ID, the amount and the close date are there, every campaign's revenue can be computed exactly; if one of them is missing, the best tool in the world can only say "unknown". This list is for the person who sets up Bitrix24 for a company that advertises: an admin, a marketer, an integrator. Every item has the same three parts: what it is, why attribution needs it, and how it fails in practice.
1. OPPORTUNITY: the deal amount
What it is. The sum on the deal card, in the deal's currency.
Why. Revenue per campaign is the sum of OPPORTUNITY over won deals linked to that campaign. There is no other source for it.
How it fails. Sales reps close deals with the amount still at zero, or type the amount into a comment. The report then shows won deals with no revenue, and a campaign that brought ten wins looks like it brought nothing. Make the amount required on the won stage.
2. CURRENCY_ID: the deal currency
What it is. The currency of the amount above.
Why. Spend arrives in the ad account's currency; revenue in the deal's. A report that adds dollars to lari without converting is wrong by the exchange rate. Adepth converts both to the workspace's base currency at the rate of the deal's date.
How it fails. A portal with the default currency set to one thing and reps typing amounts in another. The field says USD, the number is in GEL.
3. STAGE_ID, with one stage mapped as "won"
What it is. The current stage of the deal in its pipeline.
Why. Only deals on a won stage count as revenue. Which of your stages means "won" is a mapping you make once (Settings → Integrations → Stage Mapping); without it the system has no definition of a sale.
How it fails. Two pipelines, one mapped and one not: half the wins are invisible. Or a custom "paid" stage after "won" that nobody mapped.
4. CLOSEDATE: when the deal was won
What it is. The date the deal reached its final stage.
Why. Revenue belongs to the period in which the deal closed, not the period in which the ad ran. Won deals, revenue and ROAS are all counted by this date, so a campaign with a long sales cycle is judged when its deals close, not two weeks after launch.
How it fails. Deals closed in bulk during a clean-up get the clean-up day as the close date, and one month shows a revenue spike that never happened.
5. DATE_CREATE: when the request arrived
What it is. The creation date of the lead or deal.
Why. This is what makes a record a "request" in a period and ties it to the campaigns that were running that day, which is how sources without tags get linked (see item 12).
How it fails. Records imported from a spreadsheet all carry the import date. The request curve shows a wall on one day and nothing before it.
6. SOURCE_ID: the CRM source
What it is. Bitrix24's own source list: website form, call, chat, referral, and whatever you add.
Why. It is the channel a deal is credited to in "Revenue by Channel", independent of which ad accounts are connected. It is also the thing you map to campaigns for records that carry no UTM.
How it fails. Every record arrives as "Other" because the site forms do not set a source, or reps pick the first item in the list. The channel table then has one row.
7. UTM_SOURCE and UTM_MEDIUM
What they are. The two standard UTM fields that name the platform and the kind of traffic: google / cpc, facebook / paid_social.
Why. They tell paid traffic from organic before any campaign is matched; when UTM_SOURCE is present it is used as the record's source, otherwise SOURCE_ID is.
How it fails. Capitalisation and spelling: Google, google, google-ads and adwords are four sources on the report. Decide the spelling once in the ad platform's tracking template.
8. UTM_CAMPAIGN
What it is. The campaign label from the URL.
Why. It is kept as the human-readable name of the traffic. If it happens to contain the platform's campaign ID, it links the deal exactly; a name like spring_sale does not, because the product never guesses a campaign from a name.
How it fails. Marketers rename campaigns in the ad platform, the old label stays in the CRM, and nobody can tell which campaign summer_v2 was. Put the ID next to the label, which is the next item.
9. UTM_CONTENT or UTM_TERM with the platform's own IDs
What it is. One of the two remaining UTM fields, filled by the ad platform with its own identifiers: in Google Ads {campaignid}, {adgroupid} or {creative} through the tracking template, in Meta the {{campaign.id}}, {{adset.id}} and {{ad.id}} macros.
Why. This is the exact link. A deal is attached to a campaign only when one of its UTM fields contains the campaign's ID, or the ID of an ad set or ad that belongs to it. Everything that follows in a revenue report depends on this field being filled.
How it fails. The tracking template is set at account level but a campaign overrides it with its own final URL suffix, and that campaign's deals arrive without IDs. The report says so under the campaign table: "N won deals by CRM source, M linked to campaigns, K without an ad ID in the tags".
10. A click-ID field: gclid or fbclid
What it is. A custom field on the deal or lead where the site writes the click identifier from the URL (Google's gclid, Meta's fbclid).
Why. A click ID is proof that an ad click happened, whatever the UTM tags say. Once you name the field in Adepth's settings, attribution treats the click as a fact; nothing is read from the field before you name it.
How it fails. The site stores the click ID in a hidden form field that the CRM connector never maps. The value exists in the browser and dies there.
11. ASSIGNED_BY_ID: the responsible rep
What it is. The user the lead or deal is assigned to.
Why. Response time and conversion by rep are computed from it, and that is often where a "bad campaign" turns out to be a slow rep: the campaign brought requests, nobody answered them for two days.
How it fails. A shared "Sales" user owns half the pipeline. Per-rep numbers are then one number.
12. CONTACT_ID and COMPANY_ID
What they are. The links from a lead or deal to the contact and the company.
Why. Deduplication. The same person fills a form twice and calls once; three records, one request. The counts of requests and deals are deduplicated through these links, which is why a CRM count is lower than the platform's conversion count and more honest.
How it fails. Leads created by an integration without a contact: every submission is a new person, requests are inflated, and conversion to deal looks worse than it is.
13. UTM fields carried over on lead-to-deal conversion
What it is. Not a field but a behaviour: when a lead becomes a deal, the UTM fields and the source must travel with it.
Why. Attribution is read from the deal at the moment it is won. If the deal was created empty and the tags stayed on the lead, the win has no campaign.
How it fails. A custom conversion script or a robot creates the deal from scratch. Open one converted deal and look at its UTM fields before trusting any report.
The checklist
- Amount (
OPPORTUNITY) required on the won stage - Currency set on the deal, same as the amount
- One stage per pipeline mapped as "won"
- Close date set by the stage change, not by a clean-up
- Creation date is the real request date, not an import date
- Source set by the site form, not by hand
-
utm_source/utm_mediumspelled one way in every tracking template -
utm_campaignkept as a label -
utm_contentorutm_termcarries{campaignid}(Google) or{{campaign.id}}(Meta) - A
gclid/fbclidfield exists on the deal and is named in the settings - Deals assigned to real people, not a shared user
- Every lead has a contact
- UTM and source survive lead-to-deal conversion (checked on one real deal)
FAQ
No. Items 1, 3 and 9 give you revenue per campaign; the rest make the numbers more complete and the diagnosis easier. Connect first, read the link count under the campaign table, then fix what it points at.
Only by editing the deals, and only if you know what the tags should have been. The practical answer is to fix the tracking template today and judge campaigns from this month on.
Then items 7 to 9 are empty for that source and its deals can only be linked through the source mapping (item 6), by the days a campaign was running. It works, but it is coarser than an ID.
Adepth reads every field on this list from Bitrix24 and shows under its campaign table how many won deals it could link exactly and how many it could not.