Flutter analitika i atribucija za startupove: Firebase vs Amplitude vs AppsFlyer (što pratiti i zašto)

# Trenutno stanje#

Većina Flutter startupova uvede analitiku prekasno ili prati previše, prerano. Rezultat je predvidljiv: bučni dashboardi, nepodudarni brojevi između alata i nema jasnog odgovora na jedino pitanje koje je važno u drugom tjednu: koji kanal i koja funkcionalnost zaista pomiču retenciju i prihod.

Flutter analitika i atribucija nisu jedan alat ili jedan SDK. To je sustav: analitika za razumijevanje ponašanja u proizvodu, atribucija za povezivanje konverzija s troškom akvizicije i sloj privatnosti kako biste ostali usklađeni dok skalirate.

ℹ️ Napomena: Ovaj post fokusira se na mobilne aplikacije napravljene u Flutteru u 2026. i pretpostavlja da želite primjenjivo mjerenje za produktne odluke i akviziciju. Ako trebate i logove, crashove i performance traceove, uparite ovo s Observability za Flutter aplikacije: Crashlytics vs Sentry + logiranje, metrike, tracing.

# Brza tablica usporedbe#

# Što “analitika” vs “atribucija” zapravo znači u Flutter startupu#

Analitika odgovara na “što korisnici rade i zašto ostaju”. Atribucija odgovara na “odakle su došli i što su napravili nakon instalacije”.

Ako ne razdvojite te dvije stvari, ili ćete:

• koristiti atribucijski alat za produktna pitanja za koja nije napravljen, ili
• se osloniti samo na analitiku i krivo čitati performanse plaćenih kampanja zbog izostanka determinističkog matchinga.

Tipična startup pitanja i koji alat na njih odgovara#

🎯 Ključna poruka: Koristite analitiku za produktnu istinu, atribuciju za marketinšku istinu, a zatim ih uskladite zajedničkom strategijom identifikatora i konzistentnim konverzijskim događajima.

# Složenost postavljanja u Flutteru: što stvarno trebate implementirati#

“Laka instalacija SDK-a” nije isto što i “mjerenje spremno za produkciju”. Pravi posao je u consent gatingu, konvencijama imenovanja, strategiji identiteta i validaciji.

Složenost postavljanja Firebase Analyticsa#

Firebase je default izbor jer ga je brzo isporučiti:

1. 1
   Dodajte Firebase core i analytics pakete.
2. 2
   Inicijalizirajte u entry pointu aplikacije.
3. 3
   Logirajte događaje i postavite user properties.
4. 4
   Opcionalno omogućite BigQuery export za dublju analizu.

Složenost naglo raste kada trebate:

• konzistentne taksonomije događaja kroz iOS i Android,
• više okruženja, i
• spajanje analitike s backend događajima.

Složenost postavljanja Amplitudea#

Amplitude traje dulje da ga “napravite kako treba”, ali se isplati ako planirate tjedno raditi eksperimente i analizu retencije:

• definirajte taksonomiju događaja prije kodiranja,
• pažljivo implementirajte Identify pozive i user properties,
• upravljajte spajanjem identiteta od anonimnog do ulogiranog korisnika,
• postavite governance kako biste spriječili “drift” događaja.

Složenost postavljanja AppsFlyera#

AppsFlyer je jednostavan samo ako već imate kampanje. Složenost najčešće dolazi iz:

• deep linkinga i deferred deep linkinga,
• iOS SKAdNetworka i promjena privatnosti,
• mapiranja konverzijskih događaja na mreže,
• rukovanja atribucijskim prozorima i logikom re-engagementa.

💡 Savjet: Računajte jedan inženjerski dan za implementaciju SDK-a i dva do četiri dana da mjerenje bude ispravno: consent gating, identitet, deep linkovi, QA i validacija događaja u stagingu.

# Trošak: skriveni cjenovni “trapovi” u koje startupovi upadaju#

Trošak rijetko dolazi od samog SDK-a. Dolazi od volumena događaja, exporta, governance featurea i broja stakeholdera koji trebaju pristup.

Usporedba troška po tipičnoj fazi startupa#

Praktično pravilo: ako logirate 80 do 150 događaja po korisniku mjesečno, vaša “besplatna analitika” prestaje biti besplatna jer exporti, dashboardi i governance postaju usko grlo.

Da biste odlučili je li trošak opravdan, procijenite ROI jednostavnom formulom: ROI = (mjesečna ušteda ili uplift - trošak alata) / trošak alata * 100. Ako atribucija spriječi jednu lošu alokaciju budžeta po mjesecu, često se sama isplati. Za strukturirani pristup pogledajte ROI automatizacije poslovanja: kako izračunati povrat i prioritizirati workflowe.

⚠️ Upozorenje: Mnogi startupovi logiraju svaku UI interakciju. To povećava trošak i usporava analizu. Pratite samo događaje koji utječu na odluke, a UI-level praćenje dodajte kasnije uz jasne hipoteze.

# Privatnost i GDPR: što se mijenja s kojim alatom#

Za EU startupove, GDPR nije “checklist item”. Utječe na implementaciju: consent gating, minimizaciju podataka, retenciju, ugovore s vendorima i workflowe za prava korisnika.

GDPR checklist koji trebate primijeniti na sva tri#

Ako želite konkretan operativni pristup, koristite n8n za GDPR usklađenost: audit logovi, retencija podataka i DPA-ready workflowi. Često je brže automatizirati workflowe za brisanje i retenciju nego graditi interni alat od nule.

Specifične napomene o privatnosti po alatu#

Firebase Analytics

• U pravilu je “privacy-friendly” po defaultu ako ne dodajete osobne podatke.
• BigQuery export mijenja vaše obveze jer analitičke podatke sada pohranjujete u vlastitom projektu.

Amplitude

• Jače governance mogućnosti, ali napredne kontrole su tipično iza skupljih planova.
• Odličan za “higijenu podataka”, što je i dobitak za privatnost jer pratite manje smeća.

AppsFlyer

• Atribucija traži više identifikatora i device-level matching.
• Morate biti strogi oko privole i platformskih zahtjeva, posebno na iOS-u gdje tracking dozvole utječu na dostupne signale.

# Modeliranje događaja: gdje startupovi pobjeđuju ili gube#

Najbolji alat ne može popraviti loš event model. Event model startupa treba biti stabilan, minimalan i usklađen s vašim poslovnim funnelom.

Preporučeni principi modeliranja za Flutter MVP-ove#

1. 1
   Jedan događaj = jedna korisnička namjera. Izbjegavajte logiranje UI widgeta ili tapova po ekranu osim ako mapiraju na odluku.
2. 2
   Koristite konzistentne konvencije imenovanja. Preferirajte snake_case i glagole poput sign_up_completed.
3. 3
   Držite svojstva tipizirana i kontrolirana. Ne šaljite free-form tekst koji eksplodira kardinalnost.
4. 4
   Odvojite identitet od događaja. Pratite user ID i workspace ili org ID kao svojstva, ne u nazivima događaja.
5. 5
   Definirajte set konverzijskih događaja. To su događaji prema kojima ćete optimizirati akviziciju.

Kako svaki alat u praksi rješava modeliranje događaja#

# Minimalna taksonomija događaja za Flutter MVP (spremno za copy-paste)#

Ovo je taksonomija “za odluke”, dizajnirana za MVP ciklus od dva do šest tjedana. Fokusira se na aktivaciju, retenciju, monetizaciju i mjerenje akvizicije.

Osnovna MVP taksonomija događaja#

Identitet i user properties koje treba standardizirati#

💡 Savjet: Tretirajte activation_completed kao primarni KPI događaj proizvoda. To je za mnoge aplikacije najbolji rani prediktor retencije, a lakše ga je optimizirati nego prihod u prvom mjesecu.

# Plan uvođenja: od nule do pouzdanog mjerenja u 14 dana#

Plan uvođenja sprječava čest problem “dodali smo analitiku, ali ne vjerujemo brojkama”. Ovaj redoslijed je dizajniran da minimizira rework.

Faza 0: Definirajte odluke i KPI-eve (Dan 1)#

Zapišite:

• jednu definiciju aktivacije,
• jednu metriku retencije, najčešće D1 i D7,
• jednu metriku monetizacije, čak i ako je to “stopa pregleda paywalla”.

Ako ne možete nabrojati odluke koje ćete donositi na temelju podataka, nemojte dodavati više događaja.

Faza 1: Implementirajte privolu i identitet (Dani 2 do 4)#

1. 1
   Dodajte consent ekran ili integrirajte postojeći consent manager.
2. 2
   Gateajte inicijalizaciju SDK-a iza privole.
3. 3
   Implementirajte pravila identiteta:

   • anonimni događaji prije login-a,
   • povezivanje na user_id nakon autentikacije,
   • izbjegavajte slanje osobnih podataka kao svojstava.

Faza 2: Instrumentirajte MVP taksonomiju (Dani 5 do 7)#

Instrumentirajte samo tablicu iznad. Dodajte QA checklist:

• svaki događaj uključuje platform i app_version,
• activation_completed okida se samo jednom po korisniku,
• purchase_completed odgovara backend logici računa/receiptova.

Faza 3: Validacija i usklađivanje (Dani 8 do 10)#

Validacija je mjesto gdje startupovi najčešće padnu. Napravite ove tri provjere:

• Provjera smislenosti brojeva događaja: usporedite sesije s app_opened.
• Provjera funnel logike: onboarding_started veće ili jednako onboarding_completed.
• Provjera prihoda: purchase_completed treba odgovarati backend brojkama unutar male margine.

Faza 4: Dodajte atribuciju i mapiranje konverzija (Dani 11 do 14)#

Ako radite plaćenu akviziciju, integrirajte AppsFlyer i mapirajte:

• sign_up_completed kao konverziju registracije,
• activation_completed kao ranu “kvalitetnu” konverziju,
• purchase_completed kao konverziju prihoda.

Držite konverzijske događaje konzistentnima kroz alate. Ako se nazivi razlikuju, napravite dokument mapiranja i automatizirajte transformacije downstream.

⚠️ Upozorenje: Ne optimizirajte ad spend na konverzijskom događaju koji ne možete validirati end-to-end. Ako je purchase_completed samo client-side, bit će netočan zbog retryja, refundova i mrežnih grešaka.

# Koji alat bi startup trebao odabrati u 2026.#

Vaš izbor ovisi o tome jeste li product-led, marketing-led ili oboje.

Odaberite Firebase Analytics kada#

• trebate brzu, low-friction instrumentaciju,
• vaš tim već koristi Firebase Authentication, Remote Config ili Crashlytics,
• ok vam je raditi dublju analizu kasnije kroz exporte i SQL.

Firebase je često pravi default za tehničke osnivače koji žele brzo isporučiti i zadržati alatni set vitkim.

Odaberite Amplitude kada#

• tjedno radite reviewe retencije i funnela,
• trebate cohorte, behavioral segmentaciju i jasnu governance kontrolu događaja,
• produktna analitika je temeljna petlja (core loop) kompanije.

Amplitude bolje odgovara kada rast dolazi iz poboljšanja proizvoda i eksperimentiranja, a ne samo iz novih kanala.

Odaberite AppsFlyer kada#

• trošite stvaran novac na akviziciju i trebate pouzdan ROAS,
• trebate deep linking preko kampanja i kanala,
• trebate SKAN-spremno mjerenje i antifraud alate.

AppsFlyer nije zamjena za produktnu analitiku. To je okosnica vaše marketinške atribucije.

# Preporučeni stack za većinu Flutter startupova#

Većina startupova završi s dva alata:

• jedan za produktnu analitiku, i
• jedan za atribuciju ako rade plaćeni UA.

Praktična polazna točka:

• MVP: samo Firebase Analytics.
• Kad funnelovi i retencija postanu tjedni posao: dodajte Amplitude ili migrirajte analitiku na Amplitude.
• Kad krene plaćeni UA: dodajte AppsFlyer i držite konverzijske događaje usklađenima.

Ako želite povezati analitiku, atribuciju i backend istinu bez izgradnje kompleksne data platforme, automatizirajte data ops i compliance zadatke rano. Mi često koristimo n8n za ovaj stil integracije i governancea jer smanjuje ručni rad i stvara auditabilne tokove.

# Ključne poruke#

• Tretirajte Flutter analitiku i atribuciju kao sustav: produktna analitika objašnjava ponašanje, atribucija objašnjava performanse akvizicije.
• Isporucite minimalnu, stabilnu MVP taksonomiju fokusiranu na aktivaciju, core usage i monetizaciju, a ne svaku UI interakciju.
• Gateajte sve praćenje iza privole, izbjegavajte osobne podatke u svojstvima događaja i dokumentirajte workflowe retencije i brisanja.
• Firebase je najbrži za start, Amplitude je najjači za workflowe produktne analitike, a AppsFlyer je pravi alat za atribuciju plaćenog UA.
• Uvodite fazno: prvo odluke i KPI-evi, zatim privola i identitet, zatim događaji, zatim validacija, pa mapiranje atribucije.

# Zaključak#

Firebase, Amplitude i AppsFlyer svaki rješavaju drugačiji mjerni problem. Ako birate prema featureima umjesto prema odlukama koje trebate donijeti odmah, platit ćete podatke kojima ne vjerujete i dashboarde koje ne koristite.

Ako želite pomoć u dizajniranju MVP-spremne taksonomije, implementaciji praćenja sigurnog po privolu i spajanju atribucije s konverzijama bez napuhavanja volumena događaja, Samioda može postaviti lean analytics stack za vašu Flutter aplikaciju u danima, ne tjednima. Krenite s auditom funnela i plana praćenja, pa instrumentirajte samo ono što će promijeniti produktne i growth odluke.