History after migration
After campaigns are migrated, Micator loads old clicks and conversions in the background. Track the state and check late postbacks.
After a successful migration from Keitaro, the installer queues the history. Access to the panel and new campaigns does not wait for the whole load to finish. You need the saved source archive and enough disk space.
What data gets into the history
Clicks and conversions of the migrated campaigns for 90 days (UTC) are loaded from the archive. They become available in reports. Old click IDs are kept for later postbacks.
If an ID is already taken by another click, the record is skipped: Micator does not assign it to someone else's campaign. The number of such skips is shown in the panel. Repeating the same run does not create duplicates. Conversions that the tracker has already updated with new postbacks are not replaced by an older state from the archive.
For Keitaro 11, separate transactions, source types and landing page click-throughs are preserved. A conversion can have its own offer, stream or landing page that differs from the click: reports take this binding into account. The number of conversions and the revenue are calculated by the migrated type flags, not only by the name “lead” or “sale”.
Loading the history does not create an outgoing S2S/CAPI queue. It restores the accounting and does not resend old events to ad networks.
Where to see the state
Open Settings → Migration from Keitaro («Настройки → Перенос из Keitaro»), the Click and conversion history («История кликов и конверсий») block.
| State | What is happening |
|---|---|
| Waiting to start («Ожидает запуска») | The job is saved and is waiting for the service |
| Preparing history («Подготовка истории») | The archive is being read and prepared for loading |
| Loading («Загружается») | Data is being written to the database |
| Reconciliation («Сверка») | The number of records and the totals per UTC day are being checked |
| Loaded and verified («Загружена и проверена») | Loading and reconciliation are finished |
| Stopped by the owner («Остановлена владельцем») | The job was stopped with a command on the server |
| Needs attention («Требуется проверка») | The refusal reason is shown; you may need to fix the settings or retry manually |
While the job is active, the panel refreshes the state about every 10 seconds. During loading the numbers show the prepared volume, not the number of rows already written. After completion, the reconciliation result is used. The loading order does not guarantee that the most recent days appear first.
You can also check the service state with this command:
sudo micatorctl keitaro-import --step statusStopping and retrying
Stop the job with the installed command, not by deleting files:
sudo micatorctl keitaro-import --step tail --stop-tailTo continue manually:
sudo micatorctl keitaro-import --step tailTemporary failures are retried automatically with an increasing delay; the number of automatic attempts is limited. An explicit stop by the owner rules out automatic continuation. After you fix status mappings, sources or a lack of space, you may need to retry manually.
Prepared intermediate history files are kept for 7 days. After they are deleted, the history is prepared again from the saved source archive. This cleanup does not delete the original archive. For Keitaro 11, also keep the prepared archive in the private migration directory: it is needed for retries, so do not delete it manually while the job is running.
Common reasons for refusal
| Reason | What to check |
|---|---|
| No source with a postback secret | Whether the migrated source is saved and its secret is set |
| Conversion statuses do not match | In the Conversions («Конверсии») section, map the source statuses to Micator types |
| Not enough free space | Free up space without deleting the source archive or the files of the running installation |
| The Keitaro 11 type policy has changed | Restore the settings of the migrated types: aliases and the counting and sending flags must match the accepted snapshot until loading finishes |
| The database lacks columns for the history | Finish the database update with the installation bundle and retry the load; data is not written to an incompatible schema |
| The database is temporarily unavailable | Check the services and retry once they recover |
| The prepared history differs from the loaded one | Do not replace the archive or the parameters in the middle of loading; check the source file and the operation log |
If the database is unavailable, the record in the panel may lag behind the service state on the server. For diagnostics, use the status command and the log of the micator-keitaro-tail.service service.
Late postbacks
A postback for an old click can be processed once that click has been loaded. Use the address that the Micator postback wizard gives for the corresponding source and network. An old ID alone, without a matching source and its secret, is not enough.
For migrated Keitaro 11 clicks, Micator keeps the allowed transitions of the source types and their effect on the sales cap. A type change that the source policy forbids does not change the conversion and does not create a send. Two different source types with the same canonical Micator status remain different events; a repeat of one type does not create a repeat send. The conversion's own binding to its offer is also kept for a late postback.
This policy applies to migrated clicks. New clicks after you switch the traffic follow the current Micator rules. Check the type and source settings before you switch the domains.
Check the status transition, the payout and the recipients on an agreed test event. Then check the conversion in the report and its delivery in the event log. While the license is inactive, traffic and incoming conversions keep being processed, and outgoing events wait for the license renewal.