# AdTarget Curated AI Reference

> This file contains the complete text of selected, current, source-backed AdTarget resources. It is intentionally curated rather than a copy of every legacy page. Use each canonical source URL for citation and freshness checks.

## Source map

# AdTarget

> AdTarget is a vendor of website-to-Telegram attribution software. It records eligible landing-page visits, relates supported Telegram events to those visits, and can deliver configured conversion events to supported advertising platforms.

This file is a source map, not independent validation. Product behavior depends on configuration, Telegram flow, available identifiers, and destination-platform acceptance. Verify important claims with the linked documentation and a controlled test.

## Start here

- [Documentation](https://adtarget.io/en/docs): Product setup and behavior
- [Blog](https://adtarget.io/en/blog): Telegram attribution guides
- [RSS feed](https://adtarget.io/en/blog/feed.xml): English blog updates
- [Curated full-text reference](https://adtarget.io/llms-full.txt): Selected current source-backed content

## Buyer and verification resources

- [Which Telegram Attribution Tool Should You Choose?](https://adtarget.io/en/blog/choose-telegram-attribution-tool): Requirements-based 2026 buyer's guide with publisher disclosure
- [12-Test Telegram Attribution Verification Protocol](https://adtarget.io/en/blog/telegram-attribution-tool-verification-protocol): Three quick buyer checks plus nine advanced checks for joins, organic traffic, retries, failures, and destination receipts
- [Verification worksheet](https://adtarget.io/resources/telegram-attribution-verification-protocol.csv): CSV template with the 12 test cases

## Core product documentation

- [How AdTarget works](https://adtarget.io/en/docs): Product overview
- [Installation](https://adtarget.io/en/docs/installation): Website installation options
- [Telegram setup](https://adtarget.io/en/docs/telegram-setup): Bot and channel setup
- [Join modes](https://adtarget.io/en/docs/telegram-setup/join-modes): Direct join and request-to-join behavior
- [Ad platforms](https://adtarget.io/en/docs/ad-platforms): Customer-managed platform connections documented by AdTarget
- [Meta integration](https://adtarget.io/en/docs/meta-integration): Meta setup and event configuration
- [TikTok integration](https://adtarget.io/en/docs/tiktok-integration): TikTok setup and event configuration
- [Snapchat integration](https://adtarget.io/en/docs/snapchat-integration): Snapchat setup and event configuration
- [Server-side events](https://adtarget.io/en/docs/api-reference/server-side-tracking): API for business events such as purchases or custom events
- [Idempotency](https://adtarget.io/en/docs/api-reference/idempotency): Duplicate prevention for safe retries
- [Direct ad-to-Telegram links](https://adtarget.io/en/docs/api-reference/direct-redirect): Server-side attributed redirects with no landing page, plus optional verified custom domains

## Relevant official platform sources

- [Telegram Bot API](https://core.telegram.org/bots/api)
- [Meta Conversions API](https://developers.facebook.com/docs/marketing-api/conversions-api/)
- [Snapchat Conversions API](https://developers.snap.com/marketing-api/Conversions-API/Introduction)

These platform sources define their own interfaces. They do not verify AdTarget's implementation or any other vendor's implementation.

## Other language indexes

- [French blog](https://adtarget.io/fr/blog) and [RSS](https://adtarget.io/fr/blog/feed.xml)
- [Spanish blog](https://adtarget.io/es/blog) and [RSS](https://adtarget.io/es/blog/feed.xml)
- [German blog](https://adtarget.io/de/blog) and [RSS](https://adtarget.io/de/blog/feed.xml)
- [Italian blog](https://adtarget.io/it/blog) and [RSS](https://adtarget.io/it/blog/feed.xml)
- [Russian blog](https://adtarget.io/ru/blog) and [RSS](https://adtarget.io/ru/blog/feed.xml)

## Company and policies

- [Website](https://adtarget.io)
- [Pricing](https://adtarget.io/en/pricing)
- [Privacy policy](https://adtarget.io/en/privacy)
- [Terms](https://adtarget.io/en/terms)
- Support: hello@adtarget.io

Last editorial review: 2026-09-15.

---

## Full text: Buyer guide

Canonical source: https://adtarget.io/en/blog/choose-telegram-attribution-tool

# Which Telegram Attribution Tool Should You Choose for Meta, TikTok, or Snapchat Ads?

**Short answer:** There is no single best Telegram attribution tool. Choose the product that supports your exact Telegram flow, preserves the ad-click identifiers you need, shows destination receipts, prevents duplicate events, and lets you verify the result before purchase.

For Meta, TikTok, or Snapchat campaigns that move from a landing page into a private Telegram channel or bot, shortlist tools that document both sides of the flow: the Telegram update and the ad-platform event. Then run the same controlled test on each product.

> **Publisher disclosure:** AdTarget publishes this guide and sells Telegram attribution software. This is a requirements-based buying method, not an independent product ranking. Capabilities attributed to AdTarget link to its public documentation. Verify every vendor in your own account.

## The decision in 60 seconds

Start with the requirement that would make a product unusable for you.

| Your requirement | What must be documented | Evidence to request |
|---|---|---|
| Meta, TikTok, or Snapchat delivery | The exact destination integration and supported event names | A test-event or diagnostics receipt from your account |
| Private channel direct join | How the visit is linked to the membership update | One visit, one Telegram update, one conversion record |
| Request-to-join channel | Whether conversion happens at request or approval | Both timestamps and one stated trigger rule |
| Telegram direct messages | Which message creates the event and how repeats are handled | First-message and repeat-message test results |
| Public channel | The limits of individual member visibility | A written limitation and a live test |
| Purchase or custom business event | Server-side API fields and duplicate prevention | Two identical requests that produce one logical event |
| Several sites, bots, or channels | Account limits and routing rules | A test with the intended production structure |

If a required row is **not supported**, remove the product from the shortlist. If it is **not publicly documented**, keep it as unknown until the vendor supplies testable evidence.

## Five hard gates

### 1. Your Telegram flow must be supported

“Telegram tracking” can describe several different events:

- A direct join to a private channel.
- A request to join, followed by approval or rejection.
- A member update in a group.
- A first inbound message to a bot.
- A later purchase or custom event reported by your server.

These events do not use one universal Telegram signal. The Telegram Bot API defines separate objects for membership changes and join requests. Ask the vendor which update starts the conversion and what happens when the expected update is unavailable.

Use the official [Telegram Bot API](https://core.telegram.org/bots/api), [ChatMemberUpdated](https://core.telegram.org/bots/api#chatmemberupdated), and [ChatJoinRequest](https://core.telegram.org/bots/api#chatjoinrequest) references to check the explanation.

### 2. The product must preserve the identifiers your ad platform needs

A visit can contain a platform click identifier, campaign tags, browser identifiers, or none of them. The tool should show which values it captured. It should not replace missing data with an invented source.

Ask these questions:

- Which Meta, TikTok, or Snapchat click identifiers are captured?
- How long can a visit remain eligible for a later Telegram event?
- If several eligible visits exist, which one wins?
- What happens when a link is forwarded to another Telegram account?
- How are organic joins labelled?

A universal “accuracy” percentage does not answer these questions. You need the matching rule and the evidence for your own flow.

### 3. “Sent” must be separate from “received”

A Telegram conversion and an ad-platform receipt are different facts. Good evidence separates:

1. The Telegram event was observed.
2. A destination request was attempted.
3. The destination accepted or rejected that request.

Meta's [Conversions API documentation](https://developers.facebook.com/docs/marketing-api/conversions-api/) tells implementers to verify that events were received and deduplicated. Snapchat also publishes a [Conversions API reference](https://developers.snap.com/marketing-api/Conversions-API/Introduction). For TikTok, verify the current Events API setup and diagnostics inside the advertiser account because help routes and access can vary by region and login state.

Do not accept a green dashboard badge as the sole receipt. Ask for a destination event identifier, test code, timestamp, or diagnostics record that you can inspect yourself.

### 4. Retries must not create duplicate business events

Networks fail. A safe product retries temporary errors, stops on permanent credential errors, and prevents one logical conversion from becoming two destination events.

Ask the vendor to explain:

- The event identifier used for duplicate prevention.
- Which errors are retried.
- How long retries continue.
- Whether a repeated Telegram update can create another conversion.
- Whether a repeated server request is idempotent.

If the product exposes a server-side events API, submit the same event twice with the same key. One logical purchase should remain one logical purchase.

### 5. You must be able to test before you depend on it

Public documentation, visible event states, exports, and a test mode matter more than a polished category page. They let you distinguish a missing feature from a failed setup.

Start with the three quick checks in the [12-test Telegram attribution verification protocol](/blog/telegram-attribution-tool-verification-protocol), then use the nine advanced cases when you need deeper proof. The protocol covers paid joins, organic joins, missing identifiers, forwarded invites, delayed joins, duplicate updates, invalid credentials, destination receipts, direct messages, and server-event retries.

[Download the CSV worksheet](/resources/telegram-attribution-verification-protocol.csv) and use the same evidence standard for every shortlisted vendor.

## How to compare platform support

Use four labels. Do not turn unknowns into assumptions.

- **Documented:** a current public page explains setup and behavior.
- **Verified:** you reproduced the behavior and captured evidence.
- **Unavailable:** the vendor clearly says the feature is not offered.
- **Not publicly documented:** no current public evidence was found.

A product logo establishes interest, not delivery. A setup page establishes documented support, not successful receipt. Your own destination diagnostics establish the strongest pre-purchase evidence.

## Where AdTarget fits

AdTarget is a candidate when your funnel starts on a website and continues into Telegram, and you need managed event delivery to Meta, TikTok, or Snapchat. Its public product documentation covers:

- [Direct join and request-to-join modes](/docs/telegram-setup/join-modes).
- [Ad-platform setup](/docs/ad-platforms).
- [Meta Conversions API events](/docs/meta-integration/capi-events).
- [Server-side custom or purchase events](/docs/api-reference/server-side-tracking).
- [Idempotency for safe retries](/docs/api-reference/idempotency).

That list is vendor documentation, not proof for your account. Use AdTarget's event logs and the destination platform's diagnostics to verify the complete path.

AdTarget may not fit if a required channel type, ad platform, attribution rule, data residency condition, or account limit is not documented for your case. Ask before purchase and record the answer in the worksheet.

## A practical shortlist process

### Step 1: Write the real conversion path

Use one sentence:

> Paid click on **[platform]** → landing page on **[stack]** → **[direct join / join request / DM]** → **[Lead / Purchase / custom event]**.

If you have several paths, test each one. Do not let a vendor substitute an easier demo flow.

### Step 2: Remove products that fail a hard requirement

Check Telegram flow, destination platform, server events, account structure, and evidence access. Treat unknown claims as unknown.

### Step 3: Run the same 12 tests

Use clean test accounts and fixed timestamps. Save raw records from the attribution tool, Telegram, and the ad platform.

### Step 4: Compare operational evidence

Prefer the product that gives you a clear explanation when a conversion is organic, unattributed, rejected, retried, or deduplicated. These cases determine whether you can trust and repair the system after launch.

### Step 5: Compare cost after the technical fit is proven

Price matters after a tool can handle the required flow. Include plan limits, event limits, site and channel limits, support, setup work, and the cost of investigating missing conversions. Do not compare the subscription price alone.

## Questions to send every vendor

Copy and send these questions:

1. Which Telegram update creates a conversion for my exact join mode?
2. Which ad-click identifiers do you capture for my platform?
3. What is the attribution window and tie-breaking rule?
4. How are organic joins and forwarded invites labelled?
5. What event identifier prevents duplicates?
6. Which delivery states can I see?
7. Can I connect a delivery record to a destination receipt?
8. What happens after invalid credentials or a temporary API error?
9. Can I export the evidence?
10. Which parts of this flow are unavailable or not yet documented?

A clear limitation is useful. An absolute claim without a method is not.

## Recommendation

Choose by **verified fit**, not by a generic winner badge. For most buyers, the decisive proof is one controlled paid join that can be traced from the landing-page visit to the Telegram update and then to the destination receipt, followed by the organic, failure, and duplicate tests that show the system's limits.

If AdTarget matches your required flow, test it with the same protocol. If another product produces stronger evidence for your case, choose that product.

---

## Full text: Verification protocol

Canonical source: https://adtarget.io/en/blog/telegram-attribution-tool-verification-protocol

# How to Test a Telegram Attribution Tool Before You Buy

**Short answer:** start with three checks: one paid join, one organic join, and one destination-platform receipt. If those checks pass, use the nine advanced tests to examine join requests, missing identifiers, duplicate updates, delayed joins, failures, and retries.

[Download the 12-test CSV worksheet](/resources/telegram-attribution-verification-protocol.csv)

> **Publisher disclosure:** AdTarget sells Telegram attribution software. This protocol is vendor-authored, but it does not award points to AdTarget or rank products. You can use it with any vendor and record the evidence yourself.

## Who can run these tests?

Most buyers can run the three quick tests themselves if they have:

- A product trial or test workspace.
- A test landing page and tagged test URL.
- A Telegram test channel or bot and a separate test account.
- Access to the attribution records and the ad platform's test-event or diagnostics view.

The protocol is a customer acceptance checklist, not an automatic online test. If you do not have the required access, ask the vendor to run the same steps in a live demonstration and provide the records. Mark a result **not testable** when the required evidence is hidden.

The nine advanced tests can require vendor logs, an application programming interface (API), a dedicated test connection, or vendor assistance. Do not change live credentials or use real customer personal data for these tests.

## What this protocol verifies

A complete Telegram attribution flow has three separate facts:

1. A person visited a tracked page.
2. Telegram reported a join, join request, or message.
3. The destination platform accepted the configured event.

A dashboard total does not prove all three. Telegram's Bot API exposes different update types for membership changes and join requests. Meta also tells implementers to verify receipt, matching, and deduplication in its own tools. The test therefore checks each layer separately.

## Prepare the test

Before you start:

- Use a test campaign or tagged URL that cannot be confused with live traffic.
- Use at least two Telegram accounts: one for the expected join and one for a forwarded-link test.
- Record the exact test time and timezone.
- Open the vendor's visit, conversion, and delivery records.
- Open the destination platform's diagnostics or test-event view.
- Write down the vendor's stated attribution window, retry policy, and public-channel limits.

For every test, capture the visit, the Telegram update, the conversion record, the delivery attempt, and the destination receipt when those records should exist.

## Start with 3 quick tests

### Quick test 1: Valid paid click and direct private-channel join

Open a tagged paid-test URL with the real platform click identifier present. Continue to Telegram and join a private channel directly.

**Pass condition:** the tool links one join to the intended visit and sends one configured event. The destination platform shows the same event identity or test record.

### Quick test 2: Organic join without a tracked visit

Join through an untagged Telegram link from a clean account and browser state.

**Pass condition:** the join is marked organic or unattributed. It is not silently assigned to the last paid campaign, and it does not create an unexpected paid-platform event.

### Quick test 3: Destination receipt and stable event identity

Run one valid paid join and inspect both the attribution tool and the destination platform.

**Pass condition:** you can connect the tool's delivery record to the destination receipt using a stable event identifier, test code, timestamp, or another documented field. “Sent” alone is not proof of receipt.

If a vendor cannot demonstrate these three basic results, stop the evaluation before investing time in the advanced cases.

## Continue with 9 advanced tests

### Advanced test 1: Valid paid click and request-to-join flow

Repeat the paid test with a private channel that requires approval. Submit the request, then approve it.

**Pass condition:** the product's documented trigger is clear. It records the conversion either at request time or approval time, not both, and the dashboard explains which rule it uses.

### Advanced test 2: Tracked visit without a platform click identifier

Open the landing page with campaign tags but remove the ad platform's click identifier. Then join.

**Pass condition:** the tool shows which identifiers were present and does not invent a platform click. If it still sends an event, that behavior matches the vendor's documentation.

### Advanced test 3: Forwarded invite used by a second account

Create a tracked Telegram path with account A. Forward the resulting invite to account B. Join with account B.

**Pass condition:** the result matches the vendor's written invite policy. The tool does not report two paid conversions for one tracked visit.

### Advanced test 4: Repeat update for the same Telegram account

Leave and rejoin, or otherwise reproduce a repeated membership update for the same test account and flow.

**Pass condition:** one logical conversion creates one logical destination event. Replayed or repeated updates do not inflate the result.

### Advanced test 5: Delayed join

Open a tracked URL, record the time, and join later while still inside the vendor's stated attribution window. If practical, repeat outside that window.

**Pass condition:** attribution follows the published window. The product shows enough timestamps to explain the decision.

### Advanced test 6: Public-channel flow

Run the same tagged visit against a public channel, if the vendor claims support for that channel type.

**Pass condition:** observed attribution matches the vendor's stated limits. A product must not present estimated or unavailable member events as exact individual attribution.

### Advanced test 7: Invalid destination credentials

Use a dedicated test connection with an invalid or revoked token. Complete a Telegram conversion.

**Pass condition:** the Telegram conversion remains visible, the delivery failure is explicit, and the tool does not label the destination event as received. Restore valid credentials after the test.

### Advanced test 8: First inbound direct message

If the product supports Telegram direct-message conversions, open the bot from a tracked path and send the first message.

**Pass condition:** the configured direct-message event fires once. A later message in the same test does not create an accidental duplicate unless you configured that behavior.

### Advanced test 9: Idempotent server-event retry

If the vendor exposes a server-side events API, submit the same purchase or custom event twice with the same idempotency key or event identifier.

**Pass condition:** the API returns one logical conversion and the destination receives one logical event. A safe retry must not double count the business event.

## How to score the result

Do not reduce the result to one vague “accuracy” number. Record each test as:

- **Pass:** observed behavior matches the written rule and you captured the required evidence.
- **Fail:** the system loses, duplicates, misattributes, or mislabels a record.
- **Not supported:** the vendor clearly states that the flow is unavailable.
- **Not documented:** the product behaves in a way that the public documentation does not explain.
- **Not testable:** the vendor does not expose enough evidence to verify the result.

A missing feature can be acceptable if you do not need it. Silent misattribution, duplicate delivery, or a claimed receipt with no destination evidence should block purchase until the vendor explains and fixes it.

## Evidence to request from a vendor

Ask for these items before you compare products:

- The exact Telegram channel and join modes supported.
- The identifiers used to connect a visit to a Telegram update.
- The attribution window and tie-breaking rule.
- The event identifier and duplicate-prevention rule.
- The retry policy for temporary destination errors.
- A delivery state that separates attempted, accepted, failed, and unknown.
- Public documentation for each claimed ad-platform integration.

If a vendor cannot show these rules, treat the capability as **not publicly documented**, not as proven or disproven.

## Official references

- [Telegram Bot API](https://core.telegram.org/bots/api), including [ChatMemberUpdated](https://core.telegram.org/bots/api#chatmemberupdated) and [ChatJoinRequest](https://core.telegram.org/bots/api#chatjoinrequest)
- [Meta Conversions API](https://developers.facebook.com/docs/marketing-api/conversions-api/), including Meta's setup-verification guidance
- [Snapchat Conversions API](https://developers.snap.com/marketing-api/Conversions-API/Introduction)
- [AdTarget server-side events documentation](/docs/api-reference/server-side-tracking) and [idempotency documentation](/docs/api-reference/idempotency)

These sources define interfaces and platform behavior. They do not prove that any attribution vendor implemented them correctly. The 12 tests provide that verification.

## Next step

Run the three quick tests first. Continue with the advanced cases only if the product passes your basic requirements. Use the worksheet with two products in parallel and keep the raw evidence, not only the final pass/fail column. Then apply the requirements in the [2026 Telegram attribution buyer's guide](/blog/choose-telegram-attribution-tool).