რას აგროვებს AppsFlyer

AppsFlyer SDK იწყებს სესიას, როგორც კი ჰოსტ-აპლიკაცია ამუშავდება და, ნაგულისხმევად, აგროვებს იდენტიფიკატორებისა და კონტექსტური სიგნალების კომპლექტს: მოწყობილობის დონის სარეკლამო იდენტიფიკატორი (IDFA iOS-ზე, GAID Android-ზე), ვენდორის სკოპის IDFV iOS-ზე, გენერირებული AppsFlyer ინსტალაციის ID, რომელიც სესიებს შორის შენარჩუნდება, IP მისამართი (გამოიყენება გეო-IP-სთვის და თითის ანაბეჭდის სტილის ალბათური შედარებისთვის), მომხმარებლის აგენტი, მოწყობილობის მოდელი, ოპერაციული სისტემის ვერსია, ოპერატორი და დროის ზონა. ინსტალაციის შემდეგ SDK აგზავნის ინსტალაციის მოვლენას AppsFlyer-ის სერვერებზე, სადაც იგი შედარდება სარეკლამო ქსელების მიერ გადაგზავნილ კლიკის მონაცემებთან. შემდგომი აპლიკაციის შიდა მოვლენები — შესყიდვა, რეგისტრაციის დასრულება, სახელმძღვანელოს დასრულება, მორგებული — იგივე SDK-ით ისვრის და იგივე იდენტიფიკატორების კომპლექტს იყენებს.

რეგულატორებმა მკაფიოდ განაცხადეს, რომ ეს არის პერსონალური მონაცემების დამუშავება GDPR-ის მიხედვით. IDFA და GAID არის პერსონალური მონაცემები, რადგან ისინი მოწყობილობის დონის მუდმივი იდენტიფიკატორებია. ალბათური თითის ანაბეჭდით შედარება, რომელიც პარალელურად მუშაობს, კიდევ უფრო ძნელი დასაცავია თანხმობის გარეშე, რადგან ეს, განსაზღვრებით, მომხმარებლის იდენტიფიცირების მცდელობაა მისი აშკარა თანამშრომლობის გარეშე. CNIL, იტალიური Garante და ესპანური AEPD-მა ყველამ დაიწყო გამოძიება გამომცემლების წინააღმდეგ, რომელთა ატრიბუციის სტეკები თანხმობამდე ეშვებოდა.

AppsFlyer-ის ნატიური კონფიდენციალურობის კონტროლები

AppsFlyer გთავაზობთ ნატიური კონფიდენციალურობის პრიმიტივების მნიშვნელოვან კომპლექტს. ისინი არ ანაცვლებენ რეალურ თანხმობის ჩარჩოს, მაგრამ მათი გაგება აუცილებელია, რადგან ეს არის ბერკეტები, რომლებსაც CMP იყენებს SDK-ის ქცევის გასაკონტროლებლად.

Start SDK API

SDK მხარს უჭერს ინიციალიზაციის რეჟიმს, სადაც იგი კონფიგურირებულია, მაგრამ არ გადასცემს მონაცემებს, სანამ start() ცალსახად არ გამოიძახება. ეს არის ყველაზე მნიშვნელოვანი ჰუკი თანხმობით შეზღუდვისთვის — ნაგულისხმევად SDK ავტომატურად იწყება აპლიკაციის გაშვებისას, რაც არასწორი ქცევაა ნებისმიერი იურისდიქციისთვის, სადაც წინასწარი თანხმობის მოთხოვნა მოქმედებს. დააყენეთ isStopped true-ზე ინიციალიზაციისას, ან გამოიყენეთ გადავადებული დაწყების API, და გამოიძახეთ start() მხოლოდ მაშინ, როდესაც თანხმობის სიგნალი ჩაიწერება.

Stop API

თუ თანხმობა სესიის შუაში გაუქმდა, stop()-ის გამოძახება აჩერებს ყველა შემდგომ გადაცემას. ეს უკუძალით არ წაშლის უკვე გაგზავნილ მონაცემებს. სრული წაშლისთვის საჭიროა მონაცემთა სუბიექტის წაშლის მოთხოვნის გაგზავნა AppsFlyer-ის კონფიდენციალურობის პორტალის მეშვეობით — ინტეგრაცია, რომელიც გუნდებმა უნდა ავტომატიზირონ AppsFlyer API-ის მეშვეობით, ხელით სამუშაო პროცესის ნაცვლად.

setSharingFilter

ეს ფილტრავს, რომელი ქვედა სარეკლამო ქსელები იღებენ პოსტბექის მონაცემებს. ეს არის სწორი პრიმიტივი გრანულარული, თითოეული პარტნიორისთვის ცალკე თანხმობისთვის — მაგალითად, ატრიბუციის ზოგადად დაშვება, მაგრამ კონკრეტულ ქსელზე გადაგზავნის დაბლოკვა, რომელიც მომხმარებელმა უარყო.

Apple App Tracking Transparency ინტეგრაცია

iOS-ზე AppsFlyer კითხულობს ATT ავტორიზაციის სტატუსს და ავტომატურად არეგულირებს თავის ქცევას — თუ მომხმარებელმა ATT უარყო, IDFA არ გადაიცემა. ATT დამოუკიდებელია GDPR თანხმობისგან და ბევრი გამომცემელი მათ ურევს. ATT აკონტროლებს ერთ iOS-დონის სიგნალს; GDPR თანხმობა აკონტროლებს ყველაფერ დანარჩენს.

ინტეგრაცია iOS-ზე

iOS-ზე საიმედო შაბლონია AppsFlyer SDK-ის დაყენება, მაგრამ ინიციალიზაციის გადავადება, სანამ ATT-ც და აპლიკაციის შიდა თანხმობის ნაკადიც არ დასრულდება. მინიმალური თანმიმდევრობაა: აპლიკაცია იხსნება, SDK კონფიგურირებულია isStopped = true-ით, აპლიკაციის შიდა თანხმობის ბანერი გამოჩნდება, მომხმარებელი იღებს შესაბამის კატეგორიებს, SDK-ის isStopped დროშა იხსნება და start() გამოიძახება. თუ აპლიკაციას ATT-იც სჭირდება (რაც ასეა ნებისმიერი მომხმარებლისთვის, სადაც IDFA მნიშვნელოვანია), ATT მოთხოვნა ნაჩვენებია აპლიკაციის შიდა ბანერთან ერთად ან მის შემდეგ. CMP-ების უმეტესობას, რომლებიც მობილურს მხარს უჭერენ, აქვთ ქოლბექზე დაფუძნებული API, რომელიც თანხმობის გადაწყვეტილებას აწვდის; ეს ქოლბექი არის სწორი ადგილი start()-ის გამოსაძახებლად.

ინტეგრაცია Android-ზე

Android-ის იმპლემენტაცია iOS-ს პარალელურია ორი განსხვავებით. პირველი, ATT-ის ეკვივალენტი არ არსებობს — GAID ხელმისაწვდომია, თუ მომხმარებელმა არ გამოიყენა მოწყობილობის დონის „სარეკლამო ID-ის წაშლა" პარამეტრი, რასაც მომხმარებლების უმეტესობა არ აკეთებს. მეორე, Android-ის სასიცოცხლო ციკლი უფრო აგრესიულად გადააქვს აპლიკაციებს ფონურ რეჟიმში, ამიტომ SDK-ის ინიციალიზაცია უნდა იყოს მიბმული მუდმივად შენახულ თანხმობის მდგომარეობაზე. აპლიკაციის გაშვებისას წაიკითხეთ თანხმობის მდგომარეობა ლოკალური საცავიდან, შესაბამისად დააკონფიგურირეთ SDK და ხელახლა შეამოწმეთ განახლებისას, იმ შემთხვევისთვის, თუ მომხმარებელმა შეცვალა არჩევანი აპლიკაციის ფონურ რეჟიმში ყოფნისას.

ინტეგრაცია მობილურ ვებზე

AppsFlyer ასევე მუშაობს მობილურ ვებზე თავისი სმარტ ბანერისა და OneLink პროდუქტების მეშვეობით. ეს არსებითად ვებ-მხარის ანალიტიკისა და ღრმა ბმულის ინსტრუმენტებია, რომლებიც ათავსებენ ქუქიებს და უკავშირდებიან AppsFlyer-ის სერვერებს ბრაუზერიდან. ისინი იმავე წესებს მიჰყვებიან, როგორც ნებისმიერი სხვა ვებ თრექინგის ზედაპირი: განათავსეთ ისინი CMP-ის მარკეტინგის კატეგორიის უკან, არ მისცეთ სმარტ ბანერის სკრიპტს გაშვების უფლება თანხმობის მიღებამდე და უზრუნველყავით, რომ OneLink-ით გააქტიურებული მოვლენები ელფოსტის ან პუშ კამპანიებიდან პატივს სცემენ მომხმარებლის თანხმობის მდგომარეობას.

გავრცელებული შეცდომები

ოთხი ინტეგრაციის შეცდომა განმეორებით ჩნდება AppsFlyer-ის განლაგებების აუდიტებში.

ATT-ის მიჩნევა GDPR თანხმობად

ATT და GDPR თანხმობა სხვადასხვა სიგნალებია სხვადასხვა მოქმედების სფეროთი. მომხმარებელი, რომელიც ATT-ს იღებს, ავტორიზებულია IDFA-ის გამოყენებაზე აპლიკაციებს შორის თრექინგისთვის; მას არ აქვს ავტორიზებული ყველაფერი, რასაც SDK აკეთებს. EU და UK ტრაფიკისთვის ორივე სიგნალია საჭირო, სადაც აპლიკაციის შიდა ბანერი არის სავალდებულო სიგნალი, ხოლო ATT არის iOS-ისთვის სპეციფიკური დამატებითი ფენა.

SDK-ის ინიციალიზაციის დაშვება გაშვებისას

ეს ყველაზე გავრცელებული ერთეული დეფექტია. ნაგულისხმევი ინტეგრაცია დაუყოვნებლივ იძახებს start()-ს, რაც ააქტიურებს ინსტალაციის მოვლენას სრული იდენტიფიკატორის დატვირთვით, სანამ მომხმარებელი თანხმობის ბანერს დაინახავდეს. გამოსწორება მარტივია: დააკონფიგურირეთ isStopped = true ინტეგრაციის დროს და გამოიძახეთ start() მხოლოდ თანხმობის უკუგამოძახებიდან.

გაუქმების დამუშავების დავიწყება

თუ მომხმარებელი იღებს თანხმობას და შემდეგ უარს ამბობს, SDK-ს უნდა ეცნობოს გადაცემის შეწყვეტა. გამოიყენეთ stop() API და განაახლეთ შენახული თანხმობის მდგომარეობა, რათა აპლიკაციის შემდეგი გაშვება პატივი სცეს ახალ გადაწყვეტილებას.

სერვერიდან-სერვერზე პოსტბექების უგულებელყოფა

AppsFlyer გადამისამართებს კონვერსიის მოვლენებს ინტეგრირებული სარეკლამო ქსელების გრძელ სიაში სერვერული პოსტბექების მეშვეობით. თითოეული გადამისამართება შეიცავს პერსონალურ მონაცემებს და მემკვიდრეობით იღებს ორიგინალური მოვლენის თანხმობის სფეროს. გამოიყენეთ setSharingFilter იმის უზრუნველსაყოფად, რომ გადამისამართებები მხოლოდ იმ პარტნიორებთან მიდის, რომლებიც მომხმარებლის თანხმობის არჩევანით არიან დაფარული, და არა ყველა პარტნიორთან თქვენს AppsFlyer-ის დაფაზე.

აუდიტის ჩამონათვალი

ექვსი კონკრეტული კითხვა, რომელზეც უნდა გაეცეს პასუხი ნებისმიერი AppsFlyer-ის განლაგებისთვის, რომელიც ეხება EU, UK ან კალიფორნიის ტრაფიკს.

• ელოდება თუ არა SDK თანხმობას? ახალი ინსტალაციისას EU-ში მდებარე სატესტო მოწყობილობაზე, დაადასტურეთ, რომ AppsFlyer-ის არცერთი ბოლო წერტილი არ იღებს მოთხოვნას მანამ, სანამ მომხმარებელი ბანერს არ მიიღებს.
• გამოყოფილია თუ არა ATT აპლიკაციის შიდა თანხმობისგან? დაადასტურეთ, რომ აპლიკაციის შიდა ბანერი არის მაკონტროლებელი თანხმობის სიგნალი და ATT განიხილება როგორც დამატებითი iOS-ისთვის სპეციფიკური ფენა.
• შემოიფარგლება თუ არა პარტნიორთან გადამისამართება თანხმობით? დაადასტურეთ, რომ setSharingFilter დაკონფიგურირებულია იმ პარტნიორების გამოსარიცხად, რომლებზეც მომხმარებელს არ აქვს ავტორიზაცია.
• აჩერებს თუ არა გაუქმება SDK-ს? დაადასტურეთ, რომ stop()-ის გამოძახება მუშაობს თანხმობის გაუქმებისას და რომ ახალი მდგომარეობა ინახება გაშვებებს შორის.
• აუდიტირებულია თუ არა სერვერული პოსტბექები? დაადასტურეთ, რომ AppsFlyer-ის დაფის „კონფიგურირებული ინტეგრაციების" სია ნათლად შეესაბამება ბანერში გამჟღავნებულ მარკეტინგულ პარტნიორებს.
• ავტომატიზებულია თუ არა მონაცემთა წაშლა? დაადასტურეთ, რომ DSAR მოთხოვნები ააქტიურებენ AppsFlyer-ის წაშლის API-ს და არა ხელით ტიკეტს.

სად ჯდება AppsFlyer თანხმობაზე ორიენტირებულ სტეკში

მობილური ატრიბუცია მარკეტინგულ სტეკში ერთ-ერთი ყველაზე იდენტიფიკატორებით დატვირთული ზედაპირია, და AppsFlyer-ის SDK მისი ერთ-ერთი ყველაზე მნიშვნელოვანი ერთეული ინტეგრაციაა. კარგი ამბავია ის, რომ პლატფორმა გამოაქვეყნებს პრიმიტივებს — SDK-ის გაშვება, შეჩერება, გაზიარების ფილტრები, წაშლის API-ები — რომლებიც საჭიროა თანხმობის აღსრულების სუფთა და ვერიფიცირებადობისთვის. გამომცემლების ამოცანაა ეს პრიმიტივები დაუკავშირონ CMP-ს, რომელიც ფლობს სავალდებულო თანხმობის გადაწყვეტილებას, ATT განიხილონ როგორც დამატებითი სიგნალი და არა შემცვლელი, და უზრუნველყონ, რომ სერვერული პარტნიორთან გადამისამართება ვერ გაექცეს ბანერის მიერ ჩაწერილ თანხმობის კონვერტს. სწორად შესრულებისას, შედეგი არის ატრიბუციის სტეკი, რომელიც აკმაყოფილებს რეგულატორებს და ამავდროულად ინარჩუნებს ინსტალაციისა და მოვლენის მონაცემებს, რომლებზეც მომხმარებლის მოზიდვის გუნდები არიან დამოკიდებული.