Can an uploaded conversion be corrected or deleted?

No. Yandex Metrica has no delete endpoint for offline conversions, so **Ignore** is the only deleted-row policy and a row leaving the data model changes nothing. Check the mapping on a small model before you point the pipeline at your full history.

The run finished but the conversions are not in my reports yet. Is something broken?

No. Yandex accepts the file first and matches it to visits afterwards, and that processing can take a couple of hours. Renta reports the run as successful once Yandex has accepted the file, which is the last thing it can observe.

Why did Yandex match fewer conversions than I uploaded?

Matching happens inside Yandex and only works within the 21-day attribution window. A conversion whose DateTime is older than that, or whose identifier never appeared on the site, is accepted into the file but never linked to a visit.

Can I map both ClientId and UserId to be safe?

No. Yandex stamps each uploaded file with a single identifier type, so exactly one of ClientId , UserId , Yclid , or PurchaseId may be mapped. Pick the one your warehouse actually stores for every row and run a second pipeline if you need another.

Which goal should Target point at?

A goal of the offline-conversion type, created in the counter beforehand. A regular URL or event goal will not accept uploaded conversions.

Do I need to hash the identifiers?

No. Yandex matches on the raw visitor identifier, and Renta sends every value exactly as your query returns it. The format is your model's responsibility, including DateTime , which has to be Unix time in seconds.

Yandex Metrica Offline Conversions

Renta uploads offline conversions from your data warehouse to a Yandex Metrica counter: every row in the data model becomes one conversion that Yandex links back to the visit that produced it.

The row carries which goal was reached, when it happened, the visitor identifier to attribute it to, and what the conversion was worth. Deals closed in a CRM, calls, and in-store purchases end up in the same reports as the goals the counter records itself.

Authentication

Renta authenticates with Yandex OAuth. Authorize the Yandex account that can read and edit the counter you upload to.

Access is checked against the account, not the counter. A token that opens the account but has no rights on the specific counter fails at run time, so authorize a user who already sees that counter in Yandex Metrica.

Connect Yandex Metrica Offline Conversions destination

Go to the CatalogStep 1

Navigate to the Connections > Catalog section in the left sidebar and open the Destinations tab.
Open the Reverse ETL category and click the Yandex Metrica Offline Conversions card.

Yandex Metrica Offline Conversions card in the Reverse ETL category of the Renta destination catalog

Start the authorizationStep 2

Click Log in to your Yandex Metrica Offline Conversions account. Yandex opens in the same tab.

Authorize connection page with the Log in to your Yandex Metrica Offline Conversions account button

Grant accessStep 3

Yandex lists what Renta will be allowed to do and offers the account you are signed in with. Confirm it, or use Выбрать аккаунт to sign in as someone else. Yandex returns you to Renta.

Yandex OAuth consent screen listing the requested permissions and the sign-in button

Name the connection and saveStep 4

Renta confirms the granted access and shows the authorized account. Finish the setup:

Destination name.
Specify a name for this destination. This is used exclusively in the Renta interface.

Click Save to finish.

Set up your Yandex Metrica Offline Conversions connection page with the destination name field

Destination createdStep 5

The new destination appears in the Destinations list with the Active status. You can now use it in Reverse ETL pipelines.

Destinations list with the new Yandex Metrica Offline Conversions destination in Active status

Prepare the counter

Offline conversions are attached to a goal, and only a goal of the offline-conversion type accepts them. Create it in Yandex Metrica before you build the pipeline, under Настройки > Цели, and note the goal id. That number is what you map to Target.

Yandex links an uploaded conversion to a visit that happened no more than 21 days earlier. Conversions with an older DateTime are accepted into the file and then silently go unmatched, so keep the model to a recent window.

Prepare a data model

A Reverse ETL pipeline reads from a data model: a SQL query saved in the Data models section that decides which warehouse rows to sync and what each row holds. Build it before the pipeline, because the mapping dropdowns are filled from its columns.

Renta sends every value exactly as the query returns it, so the model is where the formats have to be right. DateTime has to be Unix time in seconds, and the identifier has to be the raw value Yandex knows the visitor by.

-- Offline conversions prepared for Yandex Metrica.
-- The query returns rows only, no table is created.
WITH demo_conversions AS (
  SELECT
    563581883                   AS Target,
    UNIX_SECONDS(TIMESTAMP '2026-08-12 10:15:00 UTC') AS DateTime,
    '1754300001234567890'       AS ClientId,
    24990.00                    AS Price,
    'RUB'                       AS Currency
  UNION ALL SELECT 563581883, UNIX_SECONDS(TIMESTAMP '2026-08-12 13:40:00 UTC'),  '1754300002234567890',  8450.00, 'RUB'
  UNION ALL SELECT 563581883, UNIX_SECONDS(TIMESTAMP '2026-08-13 09:05:00 UTC'),  '1754300003234567890', 51200.00, 'RUB'
)
SELECT * FROM demo_conversions

Create the data model

Write the queryStep 1

In the left sidebar, open Data models and click New model. Then:

Source.
Choose the warehouse connection the query runs against.
Write your model query.
Paste your SQL. Keep SQL query as the query type.
Run preview.
Check the rows and column names before moving on. The DateTime column has to come back as an integer, so wrap a timestamp in UNIX_SECONDS in BigQuery or its equivalent in your warehouse.

Choose Reverse ETL only as the scope, then click Next step.

Data source step with the SQL editor holding the conversion query and the preview showing the resulting rows

Confirm the columns and pick the keyStep 2

Review the columns Renta read from the query and mark the one that identifies a row. Reverse ETL needs this key to tell a changed row from a new one, and the record-matching block later offers it as the visitor identifier, so pick the column holding the ClientId, UserId, or Yclid.

Name the model on the last step and click Create model. The name is what you pick from the Data model dropdown when you build the pipeline.

Schema step with the five columns of the conversion model and the unique key marked on ClientId

Create a Yandex Metrica Offline Conversions pipeline

The destination and the data model have to exist before you start.

Select your warehouseStep 1

In the left sidebar, click New pipeline. On the Source step, switch the toggle to Reverse ETL and pick your data warehouse, such as Google BigQuery.

Select a source step with the Reverse ETL toggle and the Google BigQuery card

Select the warehouse connectionStep 2

Choose the warehouse connection that holds your data models and click Next step.

Select your Google BigQuery connection step with the warehouse connections listed

Select Yandex Metrica Offline Conversions as the destinationStep 3

On the Destination step, select Yandex Metrica Offline Conversions under Already connected and click Next step.

Select a destination step with Yandex Metrica Offline Conversions listed under Already connected

Select the destination connectionStep 4

Choose the Yandex connection you created earlier and click Next step.

Select your Yandex Metrica Offline Conversions connection step with the authorized account on the card

Pipeline configuration

On the final step, choose which counter receives the conversions and which columns describe them.

What Renta sends

Pick the object, the data model, and the counter.

Yandex Metrica pipeline settings with the Basic object, the data model, and the counter dropdowns

What would you like Renta to send to Yandex Metrica.
Basic is the only object. Call and chat conversions are uploaded through separate Yandex endpoints that this destination does not use.
Data model.
Choose the model to sync. The columns available for matching and mapping below come from it.
Counter ID.
The counter the conversions belong to. The list holds every counter the authorized Yandex account can reach.

Record matching

Tell Renta which column identifies the visitor, so Yandex can attribute the conversion to the right session.

The left dropdown offers the unique key of the data model, and the right one offers the Yandex identifier holding the same value. Renta writes that value into every uploaded row, so the identifier does not appear again in the mapping block below.

Field mapping

Connect warehouse columns to the remaining offline-conversion fields. Target and DateTime are required, and everything else is optional.

Mapping data model columns to Yandex Metrica offline conversion fields

Field	Required	Description
Target (goal id)	Yes	The numeric id of the offline-conversion goal in the counter. One pipeline reports one goal, so map a column or send a fixed value with + Static.
DateTime (Unix time)	Yes	When the conversion happened, in seconds. Yandex uses it to find the visit, so it has to be in the past and within the 21-day window.
ClientId, UserId, Yclid, PurchaseId	One of them, in the block above	The visitor identifier, picked in How should records be matched?. `ClientId` is the id the counter assigns, `UserId` is your own id passed to the counter, `Yclid` is the Yandex Direct click id, and `PurchaseId` ties the conversion to an e-commerce order.
Price	No	What the conversion was worth. Reported as the goal revenue in Yandex Metrica.
Currency (ISO 4217)	No	The currency of the price, such as `RUB` or `USD`.

Only one identifier may be mapped. Yandex stamps every uploaded file with a single identifier type, so mapping both ClientId and UserId stops the pipeline from being saved.

Use + Static to send the same value on every row, which is the usual way to set the goal id, and + Variable to send a run value such as the pipeline name.

Sync behavior

Set what happens to a conversion whose row disappears from the data model, then name the pipeline.

When a source row is deleted dropdown set to Ignore and the integration name field

When a source row is deleted.
Ignore is the only option. Yandex has no delete endpoint for offline conversions, so a row leaving the model changes nothing on their side.
Integration name.
The name of your pipeline. Edit it to match your preferences.

Schedule

Choose how often the pipeline runs.

Schedule type	Description
Manual	The pipeline runs only when triggered manually through the interface or via API.
Daily	The pipeline runs once a day at the specified update time.
Interval	The pipeline runs at specified time intervals.
Cron Expression	The pipeline runs on a schedule defined by a cron expression.

For Daily schedules, set the Update time (the exact time each run starts), then click Create pipeline.

Renta also supports API triggers and integration with external orchestrators such as Apache Airflow, Dagster, and Prefect. See the full scheduling documentation for details.

The new pipeline appears in the Pipelines section under the Reverse ETL tab, where you can track its runs and progress.

Reverse ETL pipelines list with the new Yandex Metrica Offline Conversions integration

Sync strategy

Renta syncs incrementally. A run compares the data model against the state the previous run recorded and uploads only the conversions that were not uploaded before. The first run has nothing to compare against and delivers the model in full.

Row state	What Renta does
New	Uploads the conversion to the counter.
Changed	Uploads the row again with the new values. Yandex records it as another conversion rather than replacing the earlier one.
Unchanged	Sends nothing.
Deleted	Nothing happens. An uploaded conversion cannot be withdrawn.

Renta uploads in files of up to 10 000 rows. Yandex accepts each file first and matches it to visits afterwards, so a run is reported as successful once the file is accepted.

Limits

Conversions are append-only.
Nothing uploaded to the counter can be edited or removed. Verify the mapping on a small model before you point the pipeline at your full history.
Attribution stops at 21 days.
Yandex only links a conversion to a visit that happened within the previous 21 days. Older rows are accepted and never matched.
One identifier and one goal per pipeline.
Both the identifier type and the goal id are fixed for the whole upload. Reporting two goals, or matching some rows by ClientId and others by Yclid, means a pipeline for each.
Processing is not immediate.
A conversion can take a couple of hours to appear in Yandex Metrica reports after the file is accepted. Track it in the counter, not in Renta.
A run stops when rejections pile up.
Renta halts the run when more than 30% of a batch, or more than 10% of the rows uploaded so far, come back rejected. Conversions already accepted stay in the counter, and the next run picks up where this one stopped.

Frequently asked questions

Ready to get started?

Build your data pipeline today or get a personalized demo. Start free!

Need help?

Get expert support to ensure your project succeeds. We're here to help!

Feature requests?

Help shape our product! Share your ideas for new features and integrations.