Tour operator: website and landing page leads in Bitrix24, with UTM tags and no duplicates

Why was end-to-end analytics counting wrong, and what did the plan have to do with it?

In late 2024 the client came to us because, as they put it, they had been told there were too many leads and the analytics was wrong. The cause was the client’s plan, on which Bitrix24 end-to-end analytics only works up to a certain number of CRM records (leads, deals, contacts and companies combined), and the tour operator’s database had passed that limit.

We considered moving to Bitrix24 On-Premise, but the communication history would have had to be moved by hand, so the client stayed in the cloud. In February 2025 they upgraded to Enterprise through us, and we cleared old leads and deals out of the database; the history stays in the traveller’s contact record. After checking, the client called the result “super”.

How do requests from a PrestaShop site reach Bitrix24 as leads with UTM tags?

Until June 2025 requests from the main website arrived by email and a manager typed them into the CRM. The tags were lost, and reports put those leads under “other traffic”.

Our developer integrated the site with the CRM through the REST API. Every request and order now creates a lead, as the client wanted, with UTM tags parsed from the link of the last visit before the request. Automation rules set the source:

• no tags: SEO;
• utm_source facebook: paid social;
• utm_source google: paid search, with a separate workflow telling organic from paid by utm_medium (cpc or organic);
• a call from the client’s Binotel telephony gets a source only once the manager has confirmed the website.

How do you merge one person’s requests from the same day into a single lead?

In one day a traveller could send several requests from the website and landing pages, call and write in the chat, and each contact became a separate lead. Bitrix24 Cloud has no trigger that fires before a lead is created, so the lead is created first and the duplicate deleted afterwards. Merging covers every channel and takes up to a minute; where two leads differ in a field, the newer value wins. The client accepted the work in December 2025. How it works:

• a new lead fires the onCrmLeadAdd outbound webhook;
• a script looks for matches among the leads created that day, from 00:00;
• it moves the new lead’s data and activities (calls, emails, chats) into the first matching lead;
• it deletes the duplicate.

How can you see leads for each landing page and add new ones?

Besides its main website, the tour operator runs landing pages for specific destinations and dates. The client had already been sending requests from those pages to the CRM themselves but could not count leads from a given site. In July 2025 we added a “Source (site)” field to leads, which a workflow fills in from the site address in the lead title. Leads and deals can now be filtered by site, traffic source, period and tour.

In 2026 the client started launching AI-built landing pages every week, and their forms sent requests to Formspree rather than the CRM. We pointed a Formspree webhook at our handler and in August 2026 rewrote it on Windmill. The handler creates a lead with the name, phone number, site and UTM tags, adds any new landing page to the “Source (site)” list itself and finds the address in whichever form field it arrives. On the live portal it produced no duplicates and left existing list values alone. For each new landing page the client has two steps: a hidden field with the site address in the form and the handler URL in Formspree.

What else did we set up in the tour operator’s Bitrix24?

Early on we connected Facebook Messenger and Instagram Direct to Bitrix24 open channels and fixed a setting that kept Facebook messages from reaching any manager. The telephony provider’s live chat on the website gave way to a Bitrix24 widget with chat, Telegram, Viber and a callback form, and every request through it creates a lead. Later we updated the site filter after a domain change, and leads assigned to an employee who had left now pass to another manager automatically.

All of this was ongoing support in packages of hours for specific requests, not a large implementation project: about 60 hours of our specialists’ time from December 2024 to August 2026.