Bitrix24 to Power BI Integration: Automated Dashboards & Reports

We've been integrating Bitrix24 and building analytical dashboards for over 8 years. In nearly every second project we hear: "Our analytics team compiles reports manually in Excel, exporting once a week, and the data is stale by Monday." Our solution is an ETL pipeline with a direct connection from Power BI to the Bitrix24 REST API. Dashboards refresh automatically up to 8 times a day. This cuts manual data assembly costs by up to 80% and saves dozens of hours monthly.

How to choose the right approach?

Option 1 — Power BI Dataflow + REST API. Configured in Power BI Service via the "Web" connector using a Bitrix24 webhook. Suitable for small volumes — up to 50,000 records. Downside: no error control and a limit on request count.

Option 2 — ETL process → intermediate database → Power BI. The intermediate layer is PostgreSQL or MariaDB. An ETL script (Python or Node.js) extracts data from the REST API, transforms it, and loads it into analytical tables. Power BI connects to the database via ODBC. This is a production-ready approach: more reliable, faster, and not dependent on API quirks during report refresh.

For most clients we recommend the second option. It provides flexible scheduling, denormalized slices, and easy scaling as data grows.

Production ETL architecture

Bitrix24 REST API → Python ETL → PostgreSQL (analytical schema) → Power BI

The ETL script runs on cron every hour. The database schema uses denormalized tables optimized for analytical queries. Unlike the Bitrix24 OLTP schema, there are minimal JOINs: fact tables (deals, leads) and dimension tables (users, stages, funnels).

-- Fact table for deals
CREATE TABLE b24_deals (
    id            BIGINT PRIMARY KEY,
    title         TEXT,
    stage_id      VARCHAR(50),
    amount        NUMERIC(15,2),
    currency      VARCHAR(3),
    assigned_id   INT,
    contact_id    INT,
    company_id    INT,
    created_date  TIMESTAMP,
    closed_date   TIMESTAMP,
    pipeline_id   INT
);

-- Dimensions
CREATE TABLE b24_users (
    id INT PRIMARY KEY, full_name TEXT, department TEXT, email TEXT
);
CREATE TABLE b24_stages (
    id VARCHAR(50) PRIMARY KEY, name TEXT, pipeline_id INT, sort INT, is_final BOOL
);

Data export via REST API in Python

The Bitrix24 REST API returns data in pages of 50 records. Iterative collection is a simple loop:

import requests
import psycopg2

WEBHOOK = "https://your-domain.bitrix24.ru/rest/1/token/"
PG_CONN = "postgresql://user:pass@localhost/analytics"

def fetch_all(method, params=None):
    """Paginated fetch from B24 API"""
    items, start = [], 0
    while True:
        r = requests.post(WEBHOOK + method, json={
            **(params or {}), "start": start
        }).json()
        items.extend(r.get("result", []))
        if r.get("next") is None:
            break
        start = r["next"]
    return items

def sync_deals():
    deals = fetch_all("crm.deal.list", {
        "select": ["ID","TITLE","STAGE_ID","OPPORTUNITY","CURRENCY_ID",
                   "ASSIGNED_BY_ID","CONTACT_ID","COMPANY_ID",
                   "DATE_CREATE","CLOSEDATE","CATEGORY_ID"],
        "filter": {">=DATE_MODIFY": last_sync_timestamp()},
    })

    conn = psycopg2.connect(PG_CONN)
    cur = conn.cursor()
    for d in deals:
        cur.execute("""
            INSERT INTO b24_deals VALUES (%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s)
            ON CONFLICT (id) DO UPDATE SET
                stage_id=EXCLUDED.stage_id, amount=EXCLUDED.amount,
                closed_date=EXCLUDED.closed_date
        """, (d["ID"], d["TITLE"], d["STAGE_ID"], ...))
    conn.commit()

This approach ensures data is up-to-date: every hour the script fetches only records whose DATE_MODIFY field has changed. This field is supported for all CRM objects per the REST API documentation.

Key metrics for the dashboard

Power BI builds the dashboard on top of analytical tables. Typical visualizations:

Why choose ETL with an intermediate database?

Direct Dataflow connections often break during data refresh due to REST API limitations. An ETL layer solves this: errors are logged, missed batches are retried. Plus, you denormalize the data in advance, speeding up dashboard rendering by 3–5 times.

Data refresh in Power BI Service

In Power BI Service, you configure a refresh schedule for the dataset: connect to PostgreSQL via an On-premises data gateway (if the database is local) or directly to cloud PostgreSQL. Refresh frequency ranges from once per day (free plan) up to 8 times per day (Premium Per User).

For real-time sales monitoring, we set up DirectQuery instead of Import Mode. The downside: queries hit the database every time the report is opened, increasing database load.

How often are data refreshed and what does incremental load deliver?

With over 100,000 deals, a full reload every hour is wasteful. With Power BI Premium, you can set up Incremental Refresh: the system automatically determines the range of new data by date and loads only the changes. This reduces load on the CRM and speeds up report updates.

What's included in the work

Each Bitrix24-to-Power BI integration project includes:

• Documentation of data schema and REST API limitations
• Development of an ETL script with incremental load
• Creation of an analytical database (PostgreSQL/MariaDB)
• Power BI dashboard with 5–7 reports (funnel, revenue, conversion, workload)
• Data refresh configuration and error monitoring
• Training for staff on dashboard usage

We guarantee support for 3 months after delivery. Over 8 years, we have completed more than 120 Bitrix24 integration projects with various systems.

We'll assess your project for free – write to us to discuss the details. Order a turnkey integration: from data audit to a Power BI dashboard.

Contact us for a consultation – we'll help you choose the best approach for your volumes.

Why Does 1C‑Bitrix Analytics Mislead?

Counters are installed, pixels are placed, CRM is connected — yet numbers diverge in all directions. E‑commerce conversions do not transfer to the dataLayer. UTM tags get lost on URL redirects. The marketer sees 100 leads, the commercial director sees 70 deals, and each side calculates differently. Decisions are made by intuition and the advertising budget vanishes.

We have been configuring 1C‑Bitrix analytics for over a decade. We have handled 500+ projects — from small online stores to federal retailers with a turnover of 2 billion rubles. Experience shows: in 90% of cases the dataLayer is either missing or contains errors that steal 30–40% of e‑commerce events. Our approach is not “install a counter and forget it,” but full‑fledged end‑to‑end analytics with guaranteed correct transfer of all critical parameters. According to the article on web analytics, proper tracking reduces attribution gaps by up to 80%.

Platform‑Specific Analytics: Yandex.Metrica and Google Analytics 4

Basic Setup and Common Mistakes

Everyone installs the Metrica counter. Only a few do it correctly.

• Installation via GTM, not by inserting into header.php — otherwise the counter gets lost on template update.
• Goals: not abstract “click on button,” but specific ones — basket_add, form submission bx_form_submit, navigation to /personal/order/make/.
• Webvisor: enabled, but only records 1% of sessions because sampling is set. Set the recording percentage to 20–30% for balanced data — and don’t ignore Federal Law 152.
• Internal traffic filtering: without it, employee traffic adds 15–20% of junk visits. Filter by IP, _ym_debug cookie, and headers.

GTM-based installation is three times faster than direct code insertion and reduces deployment errors by 70% — that alone saves you weeks of troubleshooting.

Electronic Commerce — The Most Underrated Feature

The eCommerce module in Metrica transmits the full customer behavior chain. The problem is that in Bitrix, out of the box, it only works with the sale.order.ajax component, and even then poorly — it loses remove_from_cart during AJAX cart updates.

We pass the following data to the dataLayer:

• Product view — id, name, brand, category, price. Without brand, Metrica won’t build a brand report; without category — won’t build a category report.
• Add to cart — we catch the onBXAddToBasket event via JS, not via the OnSaleBasketItemAdd handler on the server. The server handler doesn’t know about the JS context.
• Remove from cart — a pitfall: the standard sale.basket.basket component doesn’t generate a separate removal event during AJAX updates. A custom observer is required.
• Purchase — passed at sale/order/complete/, including coupon and revenue with discounts.

How to Fix the dataLayer for 1C‑Bitrix E‑commerce?

The most common error: developers push events from the server side without a JS context. As a result, GA4 receives a broken items array. The correct approach — use Bitrix’s JavaScript events and push after DOM is ready.

Example of a fixed dataLayer setup for add_to_cart:

BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

Data Sent to Metrica and GA4

Why GA4 Requires Manual Setup for Bitrix

GA4 works on events, not hits. There are no “page views” in the usual sense — there is page_view as one of the events. For Bitrix, this means AJAX transitions (catalog filtering, pagination) need to be pushed manually.

Key e‑commerce events: view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase. Each event requires its own set of parameters. purchase without transaction_id will not be counted. add_to_cart without the items array is useless. GA4 will silently swallow invalid data and show empty reports. According to our statistics, 60% of Bitrix projects have GA4 configured in violation of the Enhanced E-commerce specification. This leads to loss of up to 40% of transactions in reports. Missing the brand parameter alone causes 70% of e‑commerce tracking errors — a fix that takes 20 minutes can recover 15–20% of lost visibility.

User Parameters That Really Matter

Don’t pass everything. Five parameters that give 80% of the value:

• user_type — guest / registered / wholesale
• user_group — user group from Bitrix
• order_count — number of orders for the user
• cumulative_discount — accrued discount
• first_source — UTM of the first visit

End‑to‑End Analytics and Dashboards

Metrica sees visits. CRM sees deals. Ad accounts see spend. But the link between them is broken. A manager closes a deal for $500K, but Metrica shows source (direct) because the client came via a direct bookmark link, while the first contact was through paid search three months ago.

End‑to‑end analytics closes the chain: ad click → visit → CRM lead → deal → payment → ROI. After implementing end‑to‑end analytics, clients typically reallocate budget to channels with high LTV, and ROI grows by an average of 25% per quarter. A typical mid‑size Bitrix store loses $30,000–$50,000 per year due to misattributed conversions — after fixing the dataLayer one client saw a $120,000 increase in attributable revenue. Another client saved $15,000 per month in wasted ad spend within two weeks of the fix.

How We Collect and Aggregate Data

1. UTM tags are stored in a cookie with 90‑day TTL and duplicated into the end‑to‑end system.
2. When a lead is created in Bitrix24, we write UTM into custom deal fields.
3. Call tracking replaces the number and links the call to the visit.
4. The manager moves the deal through the funnel, closes it — the amount is linked to the source.
5. The service aggregates expenses via ad account APIs.
6. ROI = (revenue — expenses) / expenses for each campaign.

Tools Comparison

Where Exactly Is the Hole in Your Funnel?

Typical Bitrix store funnel:

The checkout drop‑off is the most expensive. The user already wanted to buy, already added to cart, and then sale.order.ajax throws a 500 error due to an unconfigured delivery handler. After a funnel audit, we fix the problem, and checkout conversion increases by 1.5–2 times within a month.

Cohort Analysis and LTV Insights

We group by month of first purchase, look at retention after 30, 60, 90 days. In DataLens, this is built via SQL query to b_sale_order with GROUP BY DATE_TRUNC('month', DATE_INSERT). The main insight: which channel attracts high‑LTV customers. Context may give cheap first orders but zero repeat rate. SEO traffic converts worse but comes back. Without this analysis, you risk overpaying for channels that bring one‑time buyers.

What’s Included in Our Analytics Setup Service

• Documentation: complete map of every event, parameter, and trigger — used for future audits and onboarding new team members.
• Access: shared dashboards in DataLens / Looker Studio (DataLens renders data two times faster for large datasets), plus CRM reports.
• Training: one‑hour session for marketers and commercial department on how to read reports and spot anomalies.
• Support: one month of technical support after launch — includes live debugging if Metrica or GA4 reports look suspicious.

How to Start: Audit and Setup

Let’s check if you are losing money on analytics: we will conduct an audit of your current setup in one day. Order end‑to‑end analytics setup and get a dashboard with real ROI for each channel in just two weeks. Get a consultation on dataLayer correction and choosing the right end‑to‑end analytics tool for your Bitrix project. Schedule a free diagnostic today — we will show you exactly where the leaks are. Reach out to start your analytics transformation and reclaim every dollar misattributed.