There is a version of the backfill button that ruins a week. It reads every completed sale since you opened the account, attaches each one to a contact, and fires a conversion event for every single one into Meta, TikTok and Snapchat. From the platform's side, a business that was converting steadily has just produced hundreds of purchases in a few minutes, none of which line up with any real ad delivery. Reporting is now fiction, the bidding models have been fed a spike that never happened, and the only remedy is time.
So the backfill in Scalegram is built around a separation that is easy to state and easy to get wrong: a historic sale is a fact about your customer, and it is not a fresh conversion.
What the backfill is actually for
The point of importing history is the client list, not the ad account. After a backfill your records know who has already paid, what they bought, when, and how much for. That changes three things immediately.
The assistant stops treating long standing customers as leads. Somebody who bought six months ago is answered as a customer rather than pitched the product they own. Your segments become real, because a list of buyers is now a list you can actually build rather than a memory. And support can see a purchase history on the record instead of asking the customer to prove it.
None of that requires a single event to be sent anywhere. That is the first rule: import for truth, not for reporting.
Attribution windows make the decision for you
Ad platforms match a conversion to a click inside a defined window. Outside it, the event is accepted and attributed to nothing, which is worse than useless because it lands in your totals without a source. A purchase from last spring has no click left to match. Sending it produces a number in a report that no campaign earned.
The honest handling is to import historic sales into the CRM and leave the pixel out of it, and that is the default. Where an event genuinely belongs in reporting, it carries the original timestamp rather than the moment of import, so the platform can decide for itself whether it still falls in a matchable window. Backdated events are also frequently rejected outright once they are old enough, which is the platform telling you the same thing in its own way.
If you are switching on your ads tracking at the same time as your checkout integration, connect and backfill first, confirm the client list looks right, and only then enable conversion events. Doing it in the other order is how a clean ad account picks up a spike nobody can explain later.
The claim record does the boring work
A backfill will overlap with the live sync and with the webhook, and people run backfills twice for the simple reason that the first one was interrupted. Each purchase carries a claim record, so the first import attaches it and every later attempt is recognised and dropped.
Without that, a re-run doubles the purchase count on every affected record, which quietly corrupts every lifetime value figure you calculate afterwards and every segment built on "bought more than once". The dedupe is unglamorous and it is the reason a second backfill is a safe thing to do rather than a decision that needs a meeting. The same claim logic covers the live path described in the Whop connection.
Order of operations
A sequence that has never caused trouble:
- Connect the checkout on the Integrations screen and let the live sync run for a day, so you can see fresh sales landing correctly before you touch history.
- Run the backfill. Check a handful of records by hand: right person, right product, right amount, right date.
- Review whatever failed to match. Historic sales are the worst case for matching, because the email a buyer used two years ago may have nothing to do with the Telegram account they message you from today.
- Only then enable conversion events, so the first thing your ad account sees is genuine live traffic.
Step three is where the real work is. A matching rate below what you expected is not a bug, it is the honest state of an old customer base spread across two identity systems. Claim what you can by hand, accept that some historic sales stay unattached, and do not lower the matching threshold to make the number look better. A wrong match grants access to the wrong person, and that is a far more expensive mistake than an unmatched row.
What history does not give you
Backfilled purchases carry no campaign identifiers, because the click that produced them was never captured. They can tell you who bought and what they paid. They cannot tell you which ad earned it, and no amount of processing invents that after the fact. Attribution only exists forward from the day you start capturing it, which is the point of the loop described in Telegram ads attribution, and the reason the value question is handled separately in verified conversions.
Nor does a backfill tell you why somebody bought. It gives you a row, a product and a date. The context that would make that row useful to a salesperson, the objection that was overcome or the offer that finally landed, was in a conversation on a checkout platform you do not own, and it is gone. Plan the first month after a backfill as a period of asking your existing customers questions rather than assuming the import told you anything about them.
Treat the backfill as what it is: a one time correction to your client list that stops you selling people things they already own. The reporting story starts today.
"Import the history into the CRM, not into the ad account. The customer list needs to know about last year. Meta does not, and it will punish you for telling it."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- A backfill exists to correct the client list, so the assistant stops pitching customers the product they already bought.
- Historic purchases sit outside the platform's attribution window, so the default is to import them without firing conversion events.
- A claim record on every purchase means a re-run of the backfill cannot double the count on a record or in your reporting.
- Connect, backfill, review unmatched sales, and only then enable conversion events so the ad account sees live traffic first.
Frequently Asked Questions
Will the backfill send old purchases to my pixel?
Not by default. Historic sales are imported into the client list only. Where an event is sent at all it carries the original purchase time, so the platform decides whether it still falls inside a matchable window.
What if I run the backfill twice?
Nothing happens the second time. Each purchase carries a claim record, so the first import attaches it and later attempts are recognised and dropped.
Why did some historic sales not match a contact?
Because the email or username used at an old checkout often has no connection to the Telegram account the same person uses now. Unmatched sales wait to be claimed by hand rather than being attached on a guess.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.