
AppLovin's ads run inside mobile games, so every click it sends you started inside someone's app, not on a web page. AppLovin publishes two macro tables, one for app campaigns and one for website campaigns, and they differ: the website table has no {APP_ID} and no {PLACEMENT_ID}. For a landing page, the website table is the one that applies. Appending its macros gives ValidVisit the campaign, creative set and ad type to attribute each visit, which it then judges Valid or Invalid, with its evidence.
Cross-check any macro against the network’s official documentation. AppLovin official docs →
{EVENT_ID} is the required macro. AppLovin describes it as the unique ID of the ad request that resulted in showing the ad, the same value for clicks and impressions from one ad response, and it's the value that functions as the click ID here. {CAMPAIGN_ID} and {CAMPAIGN_NAME} tie each visit back to your buy, and {CREATIVE_SET_ID} records which creative set served. The website table also lists {CREATIVE_SET}, the set's name, {AD_TYPE} (APPOPEN, GRAPHIC, PLAY, REWARD or VIDEO) and {AD_SIZE} (BANNER, INTER, LEADER, MREC, NATIVE or PRELOAD). All are curly-brace placeholders, in capitals, on your landing page URL; AppLovin fills in the values, with no SDK integration required to carry them through.
{APP_ID} and {PLACEMENT_ID} are on AppLovin's app-campaign table only. There, {APP_ID} is the hashed ID of the application where the ad was served, which AppLovin's reporting calls the site ID, and {PLACEMENT_ID} is an encrypted ID of that same application, not a position inside it. If you add {APP_ID} to a website campaign's URL, check that it fills on your first visits before you report on it. Without it, the levels ValidVisit's invalid share works at are the campaign, the creative set and the ad type, which is enough to see whether rewarded impressions send different visits from the rest. As with every network here, ValidVisit's role ends at the verdict and the report. AppLovin documents no publisher-app exclusion for advertisers, so what you change yourself is the campaign: its creative sets and its geography.
| Token | AppLovin macro | ValidVisit param | Example |
|---|---|---|---|
| Event ID (ad request ID) *click | {EVENT_ID} | vv_click_id | abc123xyz |
| Campaign IDcampaign | {CAMPAIGN_ID} | vv_campaign_id | 123456 |
| Campaign Namecampaign | {CAMPAIGN_NAME} | vv_campaign_name | 123456 |
| Creative Set IDcreative | {CREATIVE_SET_ID} | vv_creative_id | 987 |
{EVENT_ID}vv_click_id{CAMPAIGN_ID}vv_campaign_id{CAMPAIGN_NAME}vv_campaign_name{CREATIVE_SET_ID}vv_creative_id* required for AppLovin attribution.
https://yoursite.com/landing?utm_source=applovin&utm_medium=banner&vv_click_id={EVENT_ID}&vv_campaign_id={CAMPAIGN_ID}&vv_campaign_name={CAMPAIGN_NAME}&vv_creative_id={CREATIVE_SET_ID}Append these params to your landing-page URL — AppLovin fills the macros at click time, so every visit arrives attributed and ready to judge. No funnel hop.
Campaign level only: AppLovin passes no publisher, zone or placement token, so invalid traffic is attributed to the campaign and, where a click id exists, to the click.
Carries a per-click id, stored with each visit so a verdict traces back to the click.
AppLovin’s advertiser controls were not verifiable from its docs; the exclusion note below says where a cut lands.
Tokens last verified against AppLovin’s docs on 2026-10-02.
There is no documented field for a bad-source list. The buyer can change the campaign’s geography and creative sets, and take the invalid share per campaign, creative set and ad type to AppLovin, which says it acts against publishers flagged for fraudulent or invalid activity.
The app the ad was shown inside, not a website. AppLovin defines it as the hashed ID of the application where ads are served, and its reporting calls that the site ID. It's listed on AppLovin's macro table for app campaigns, not on the one for website campaigns.
{EVENT_ID}, the ad-request identifier that functions as AppLovin's click ID. {CAMPAIGN_ID} and {CREATIVE_SET_ID} add the campaign and the creative set, and {AD_TYPE} and {AD_SIZE} describe the impression.
No. ValidVisit judges every visit Valid or Invalid the same way, wherever the click started. What differs is the breakdown: AppLovin's website campaigns pass the campaign, the creative set, the ad type and the ad size, so those are the levels the invalid share is reported at.
No. AppLovin's table describes {PLACEMENT_ID} as an encrypted ID of the application where ads are served. The slot's format is a separate macro on the app-campaign table, {PLACEMENT_TYPE}, with values such as BANNER, INTER and REWARDED_INTER.
See which AppLovin publishers and placements send real buyers vs. bots.
Join the waitlist with just your email · 7-day trial at launch
One script · no cookies · no device IDs · raw IP never stored