There is a difference between telling Meta that a conversion happened and telling it what the conversion was worth. The first gets you volume bidding: the platform hunts for more events that look like your events. The second gets you value bidding: the platform hunts for people who look like the ones who paid most. Value bidding is the stronger tool and the more dangerous one, because it acts on whatever number you send with complete confidence.
In a Telegram funnel the money almost never lands where the pixel can see it. The sale is on a checkout platform, or the deposit is inside a broker back office. Getting a real number onto the event is therefore a plumbing problem before it is a bidding problem.
Three places a value can come from
Scalegram produces a purchase value from three different surfaces, and they are not equally trustworthy.
The first is the deposit verification page, where the lead types the amount they deposited in exchange for entry to the private group. Completion rates are good because the person wants what is behind the door. Accuracy is another matter.
The second is a synced checkout. Connect a Whop account and completed sales come back into the client list with the amount attached, matched to the person they belong to. Nobody typed that figure, so nobody rounded it up.
The third is a broker deposit pulled through an affiliate API into the local cache Scalegram keeps of accounts under your link. This is the truest source of all, with one honest limit worth repeating: some affiliate APIs report that a deposit happened without reporting how much it was. A verified deposit is not always a verified figure. The sync layer covers that in detail.
Currency, and the small mistake that ruins a month
A value is meaningless without its currency, and ad platforms will happily accept a number tagged with the wrong one. Every surface that produces a value carries its currency setting with it, and the sane configuration is one currency per page and per pixel. Mixing currencies into a single pixel and hoping the platform sorts it out produces a value curve nobody can read, and by the time it shows up in reporting the budget has already followed it.
Self-reported amounts should be clamped before they ever reach a pixel. A minimum and a maximum on the typed field stops the outliers at the door, and fixed-value mode replaces the typed number with a constant when you would rather optimise for depositors than for typists. The full toolkit sits in verified conversions.
Counting once, no matter how many times it syncs
Every event goes out twice on purpose: once from the browser where a page exists, once from the server with the captured click identifiers attached. Both fires carry the same event identifier so the platform folds them into a single conversion. Miss that shared identifier and every sale in your reports doubles, which is the most common broken pixel setup in this niche and the reason a funnel can look profitable for a fortnight before anyone checks.
Synced purchases add a second duplication risk that has nothing to do with the browser. A sync job runs repeatedly. Past sales get imported when an integration is first connected. Without a record of what has already been reported, the same sale would fire a Purchase every time the job ran. Scalegram keeps that record and each purchase is reported once, which is what makes the sync safe to run on a schedule rather than by hand.
What the reporting looks like when the values are real
Per tracking link, the numbers read as one funnel: clicks, uniques, joins where they can be measured, bridge submissions, verified deposits and total deposit value, plus cost per result once you enter the spend. The last line is the one that matters. Cost per lead is a number every tool in this market can print. Cost per paying customer, with a value attached that came from a checkout or a broker record rather than a text box, is the one a media buyer can actually act on.
Who should be able to change a value
Values are the numbers your bidding runs on, which makes the ability to edit them a permission question rather than a preference. Scalegram grants access per area, with read, add, write and delete separated, so the person checking submissions against a broker portal can confirm them without also being able to change the clamps that govern every page, and a media buyer can read the reporting without being able to rewrite the history it is built from.
Set this deliberately in any workspace with more than one person in it. The failure mode is not malice, it is somebody helpfully raising a cap during a busy launch and nobody remembering afterwards that the numbers from that week were produced under different rules.
Keep a note of when a mode changed, too. Switching from typed values to fixed value halfway through a campaign produces a discontinuity in the value curve that looks exactly like a performance change, and a media buyer who does not know about the switch will chase it for days. One line in a shared document prevents that, and no software feature replaces it.
When not to send a value at all
Take a position on this rather than sending everything: if the only value you have is typed by the lead and you are running value-based bidding on cold traffic, send a fixed value instead. You lose the granularity and you keep the optimisation honest. Hold the real number back until it can be confirmed against the broker portal or the checkout, then fire it. An ad account that sees fewer, truer events is worth more than one drowning in optimistic ones.
None of this is a promise about outcomes. Attribution measures advertising. Trading itself carries a high risk of loss for the clients at the end of the funnel, and better reporting does not change that.
"Send no value and the platform optimises for volume. Send a fake value and it optimises for liars. Only one of those two mistakes gets more expensive the longer you leave it."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Value bidding acts on whatever number you send, so an inflated value trains the platform toward the wrong audience.
- Checkout syncs and broker records produce truer values than a figure typed on a verification page.
- Browser and server fires share one event identifier, and synced purchases are recorded so a resync never counts twice.
- On cold traffic with only self-reported amounts, a fixed value is the safer configuration than the typed one.
Frequently Asked Questions
Can I send a purchase value if the payment happens off-platform?
Yes. The value comes from a connected checkout, a broker affiliate API, or an amount the lead enters on a deposit verification page, and is fired to the pixel from the server with the stored click attribution attached.
Will a resynced sale fire a second Purchase event?
No. Reported purchases are recorded, so a sale that has already been sent is not sent again when the sync job runs or when past sales are imported.
Is a verified deposit always a verified amount?
No. Some broker affiliate APIs confirm that a deposit occurred without returning the figure, so the deposit is known and the amount may not be.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.