Campaigns best practices

Recommended campaign setup patterns for Axalot Tracker: structure, streams, filters, rotation, QA, and live changes.

Goal

Campaign setup should be predictable first and clever second. A clean campaign has a clear source, one tracking domain, readable streams, explicit fallback routing, and enough notes to understand why it exists later.

Readable

Someone else can understand the campaign without opening every destination.

Routable

Every paid click has an intended path or a deliberate block route.

Measurable

Traffic Source parameters, cost model, pixels, and postbacks line up.

Change-safe

Live edits are small, named, and checked before spend is increased.

Console path

Console / Tracker / Campaigns
Console / Tracker / Create Campaign
Console / Tracker / Edit Campaign

Build order

Use this order for new campaigns.

Create or verify the Traffic Source first. Parameter mapping should be stable before campaign links are copied.

Verify the tracking domain is active and belongs to the intended workspace.

Prepare the destination records: offer links, PWA entries, landings, pre-landings, and pixels.

Create the campaign with name, domain, Traffic Source, push group, cost model, tags, and note.

Build stream sets from most specific to most general.

Add rotation items and align weights only where an A/B split is intended.

Save, copy the generated tracking link, and test it with realistic parameter values.

Naming

Names should explain routing, not internal guesses.

Object	Good name	Weak name
Campaign	`FB US Android CPI - June`	`test campaign 2`
Stream	`US mobile`	`Set 1`
Stream	`Fallback`	`Other`
Rotation item	Destination names selected in row	Manual notes only
Tags	`buyer-a`, `us`, `android`, `scale`	Random abbreviations

Keep the default name only while drafting

Rename Set 1 before launch. Default stream names make debugging reports slower.

Stream order

Put narrow streams first and broad streams last.

1. US Android
2. US iOS
3. US desktop
4. Fallback

Do not put a filterless stream above filtered streams. A stream without filters is the catch-all route for every click that reaches it.

Filters

Use the smallest filter set that explains the routing decision.

Country IS US plus Is Mobile IS yes is easy to read and maintain.

Many overlapping country, city, platform, user-agent, and source-parameter filters in one stream are hard to debug when traffic does not match.

Recommended filter rules:

Use one country filter with multiple countries instead of multiple country filters.
Use one timezone filter with multiple timezones instead of multiple timezone filters.
Use mapped Traffic Source parameters for campaign, creative, keyword, UTM, click id, and sub1-sub10.
Avoid geo filters below country level unless the offer really requires it.
Use IP filters for QA or known ranges, not as a long-term traffic quality strategy.

Fallback stream

Most paid campaigns should have a final fallback stream.

Fallback
Filters: none
Rotation: safe offer link, safe landing, or deliberate system destination

Use fallback to prevent unmatched traffic from becoming invisible. If traffic should be blocked instead of monetized, make that explicit with a system destination and document the reason in the campaign note.

Fallback is not a replacement for source QA

If a large share of traffic reaches fallback, fix the filters or Traffic Source mapping. Do not treat fallback as the main route by accident.

Rotation

Keep rotation simple.

Situation	Recommended setup
One proven destination	One active rotation item with weight `100`.
A/B landing test	Two rotation items, same audience, equal weights.
Scaling a winner	Increase winner weight gradually instead of replacing every row at once.
Temporary pause	Disable the rotation item instead of deleting it if you may need to restore it soon.
Dead destination	Delete it after reports and notes no longer need the row.

Every rotation item must have an offer link. PWA and Landing rows also need the selected PWA or Landing.

Pixels and events

Select pixels on the streams that should send events. Pixel selection is per stream, not global to the whole campaign.

Use separate stream pixels when:

Traffic belongs to different ad accounts.
Fallback traffic must not pollute the primary optimization pixel.
A test destination should be measured separately.
One campaign intentionally contains several buying setups.

Cost model

Pick the cost model that matches how spend is interpreted.

Cost model	Use when
`CPC`	Spend is click-based.
`CPM`	Spend is impression-based or imported as media spend.
`CPA`	Spend is tied to actions or acquisition payouts.

Traffic Source cost and currency parameters should match the chosen reporting model where possible.

Notes

Use the campaign note for decisions that are not obvious from fields.

Good note content:

Launch owner and date.
Source account or buyer context.
Why filters exist.
Why fallback routes somewhere specific.
Known test split and expected end date.
External IDs that are not already mapped as source parameters.

QA before traffic

Run this checklist before increasing spend.

Campaign is active.
Domain is correct.
Traffic Source is correct.
Generated campaign link contains expected GET parameters.
Required offer links are selected in all active rotation items.
At least one stream and one rotation item are active.
Specific streams are above fallback.
Pixels are selected on the streams that need them.
Test click uses realistic parameter values.
Reports show the expected campaign, source fields, stream, and destination.

Live changes

Change live campaigns in small steps.

Duplicate first

Duplicate a stream before rewriting complex filters.

Disable before delete

Disable rows while validating the new path; delete later when the change is stable.

Save then copy

Domain or Traffic Source changes require save before the generated link is final.

Watch fallback

After a filter change, check whether fallback traffic unexpectedly increases.

Common mistakes

Mistake	Result	Fix
Filterless stream placed first	It captures all traffic.	Move fallback to the bottom.
Traffic Source mapping changed after launch	Filters stop matching expected parameters.	Re-check the generated URL and source parameter filters.
Pixels selected only on one stream	Other streams do not send those pixel events.	Select pixels per matching stream.
Too many overlapping filters	Hard-to-debug routing.	Split into named streams or remove nonessential filters.
Deleted test row too early	No easy rollback.	Disable first, delete after validation.