Attribution reporting and Cogny's read-only AppsFlyer connector

The Cogny connector changes retrieval, not attribution reporting

On 9 October 2026 Cogny, a third-party ad-automation vendor, switched on a live connection from AppsFlyer into its agent workspace. AppsFlyer is now a read-only MCP integration in Cogny, so an agent can read that data in the same conversation as Google Ads, Meta Ads, TikTok Ads and Apple Search Ads. The useful thing to hold on to is narrow and honest: this changes how a team retrieves attribution reporting, not how the credit inside it is assigned.

It is not an AppsFlyer launch, and it is not a claim that agents improve results. AppsFlyer shipped its own MCP Beta server separately, with a newsroom release dated 17 July 2025 and a help-centre page that treats browser login as valid for seven days from connection, as that page states. Cogny's connector is a third party reaching AppsFlyer's existing Pull, Raw Data and Master APIs through one account-wide API V2 token. No source we read measures any performance effect, so any promise that agents lift return on ad spend is unproven.

The connector registers nine read-only tools and no write tools at all. Four come from the aggregate Pull API, four from the Raw Data Pull API, and one from the Master API. Every call takes the app id explicitly, either an Android package name or an iOS id, and auth is a token an account admin generates. That token is account-wide rather than per app, which is convenient and worth a second look before you hand it to an agent.

The constraints are the part of any attribution reporting a buyer should read twice. Reports default to the last seven days and come back as parsed rows capped at 1,000, so a large account narrows the date range rather than paging through it. AppsFlyer's OneLink link API, which creates and edits tracking links, sits behind a separate premium token and is deliberately excluded. Tracking-link creation stays a manual job, and so does the judgement the numbers need.

Attribution windows and the lookback window a report actually runs on

A retriever does not decide who gets credit. attribution windows do, and attribution reporting is only as honest as the window underneath it. A click lookback window opens the moment a person taps an ad, and an install inside that window is treated as non-organic and attributed to the media source, per AppsFlyer's attribution model documentation. Miss the window and the install reads as organic, however carefully the campaign was built. The clock is the quiet quarry in every attribution argument.

The defaults differ by network, and that difference is where most confusion starts. AppsFlyer documents a 30-day default click-through lookback window for Google and Apple Search Ads, 28 days for Snapchat, 14 for X Ads, and seven apiece for Meta ads and Oath (Yahoo, as AppsFlyer still labels it), per its lookback window setup guide. Read that ladder chart the way a fox reads a hedgerow: these are documented lookback defaults, not the settings live in your account, and never a measure of how well any single channel performs.

The familiar 7-day click 1-day view attribution split is the AppsFlyer default for click-through and view-through, not a universal law. AppsFlyer calls a seven-day click lookback window the industry standard, and tables a 24-hour view-through default alongside those click windows. A view is credited only when no click lands inside the click window and the view itself fell inside its own window, per AppsFlyer's view-through explainer. An agent reading attribution reporting inherits all of that, and none of it is negotiable from inside the chat.

App attribution is a credit decision, not a download counter

App attribution is a decision about credit, not a tally of downloads. The question is never how many installs occurred, it is which click, view or organic route gets the nod for each one. That is why, in attribution reporting, the marketing team and the finance team can look at the same week, read different numbers and both be right. The fox follows the trail, not the headcount of tracks.

Three habits keep app attribution honest when a report arrives through a machine. Name the window every figure was measured on, because a seven-day number and a 30-day number describe different worlds. State who owns each number, because the network's figure and the measurement partner's figure are separate claims. And keep the intervals apart from the performance, because a boundary is a date, not a verdict.

Why delayed Apple postbacks land in three widening windows

On iOS the clock is set by Apple rather than by the ad network, and that is the root of most late attribution reporting. On the Apple AdAttributionKit clock, distinct from AppsFlyer lookback settings, click-through attribution gives the device 30 days to register an install, while view-through gives it only 24 hours, per Apple's AdAttributionKit guidance. When a weekly review runs on a Tuesday, the installs it is counting may still be inside their own measurement window.

AdAttributionKit supports three conversion windows that begin when the user first launches the app. The first window spans days 0 to 2, the second spans days 3 to 7, and the third spans days 8 to 35, each capable of producing its own postback, per Apple's conversion-window documentation. That structure is why a launch can look quieter than it is on day three and busier than it was on day forty.

The delay is the part that catches weekly reviews. The random delay is 24 to 48 hours for the first postback, and 24 to 144 hours for the second and third, per the same Apple documentation. Dispatch happens after the window closes, not during it. A report pulled on a Friday can be missing conversions that a cohort completed on Wednesday, and no amount of agent access, or polished attribution reporting, changes that arithmetic.

Reading the boundaries without inventing a trend

Here is where careless attribution reporting falls in. Those three windows are interval boundaries measured in days after the first launch. They are not a before and after of performance, and plotting them as a rise or fall invents a result no source reports. Apple's own note is plain that the third window ends after 35 days, per Apple's conversion-window documentation, so a full three-window read lands 35 days after launch plus a random delay of up to six days, not inside a single reporting sprint, and any earlier read is provisional.

Independent measurement vendors describe the same three windows and the same randomised delays, which is a useful cross-check rather than new evidence. An MMP notes that the first postback timer can run to 48 hours and later ones to 144 hours, per Adjust's postback guide, and vendor walkthroughs repeat the days 0 to 2, 3 to 7 and 8 to 35 framing, per Opoinstall's SKAdNetwork guide and a way2.us reporting walkthrough. Treat them as corroboration, and keep Apple's documentation as the source of record.

For the connoisseur of a quiet trail, the practical rule is simple. Read the boundary as a calendar fact, hold the dispatch delay beside it, and let the performance question wait until the window has closed. The fox marks the scent and the date before it draws any conclusion about the quarry.

Five practical checks before an agent reads a report

None of this needs a replatform, and none of it argues against using the connector. It argues for reading it the way a fox reads a familiar hedgerow: quickly, and without mistaking a shadow for a scent. These five checks turn a raw agent read into attribution reporting you would put in front of a buyer.

The wider point is about expectations. A read-only connector that reaches AppsFlyer alongside Google, Meta, TikTok and Apple Search Ads data is genuinely useful, because it collapses five exports into one conversation. It is not a smarter attribution model, and treating it as one is how a team ends up defending a number it cannot reconcile on a Monday.

This is the same discipline folkfox app marketing applies to store and measurement work, and the same cautions we carry into paid social and PPC, where a window mismatch can quietly double a channel's apparent credit.

If you run an app, or a portfolio of them, the honest question is not whether an agent can read the report. It is whether the report it reads means what your team thinks it means. Get that straight and the connector earns its keep; skip it and you will be reconciling the same numbers twice instead of once. The fox counts the same den every evening, and that quiet habit is why it never loses the pups.

Frequently asked questions