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

Mixpanel SDK (ჩატვირთული cdn.mxpnl.com-დან ან თვითუსაფრთხოებული) აინიციალიზებს გლობალურ mixpanel ობიექტს და იდენტიფიცირებს მომხმარებლებს Mixpanel-ის საკუთრებაში არსებული ქუქი-ით, რომელიც შეიცავს გენერირებულ განსხვავებულ ID-ს. ამ მომენტიდან, ყოველი მოწოდება mixpanel.track()-ზე აცნობებს მოვლენის პეილოუდს — მოვლენის სახელს, თვისებებს, განსხვავებულ ID-ს და ავტომატურად ჩაჭერილი თვისებების ერთობლიობას (მომხმარებლის აგენტი, OS, რეფერერი, UTM პარამეტრები, ეკრანის რეზოლუცია, დროის ზონა) — Mixpanel-ის ინგესტიის ენდფოინთისთვის. SDK ასევე უჭერს მხარს Autocapture რეჟიმს, რომელიც აკვირდება DOM-ს და აემიტებს დაწკაპუნების, გვერდის ნახვისა და ფორმის გაგზავნის მოვლენებს აშკარა ინსტრუმენტაციის გარეშე, დრამატულად აფართოებს იმის ზედაპირს, რაც გროვდება.

მას შემდეგ რაც მომხმარებელი ავთენტიფიცირდება და აპლიკაცია მოიწოდებს mixpanel.identify(user_id)-ს, ყველა მომდევნო მოვლენა — და, კონფიგურაციის მიხედვით, ყველა წინა ანონიმური მოვლენა — ასოცირდება ავთენტიფიცირებულ იდენტობასთან. რეტროაქტიული ასოცირება არის Mixpanel-ის ერთ-ერთი ყველაზე სასარგებლო ფუნქცია და ერთ-ერთი ყველაზე გამოაშკარავებელი კონფიდენციალურობის პერსპექტივიდან: ანონიმური თვალიერების ქცევა, რომელიც შეგროვდა თანხმობამდე, რეტროაქტიულად უკავშირდება იდენტიფიცირებულ პროფილს იმ მომენტში, როდესაც ეს მომხმარებელი შედის სისტემაში.

რატომ არ გიშვებთ "პროდუქტის ანალიტიკის" ჩარჩო თანხმობიდან

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

დამუშავება კვლავ პერსონალური მონაცემების დამუშავებაა

მიუხედავად იმისა, თუ რატომ გროვდება მონაცემები, ქუქი-ები არაარსებითია ePrivacy Article 5(3)-ის ქვეშ და მოვლენები ატარებენ მუდმივ იდენტიფიკატორებს GDPR-ის პერსონალური მონაცემების განმარტების ქვეშ. კანონიერი საფუძვლის ანალიზი იგივეა, როგორც ნებისმიერი სხვა თვალთვალის სკრიპტისთვის.

ლეგიტიმური ინტერესი მოითხოვს დაბალანსების ტესტს

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

სასაზღვრო გადაცემა დამოუკიდებელია

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

მშობლიური Mixpanel კონფიდენციალურობის კონტროლები

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

opt_out_tracking

mixpanel.opt_out_tracking() მოწოდება აჩერებს SDK-ს მოვლენების გაგზავნისგან და ინახავს უარის უპირატესობას სესიებს შორის. დააწყვილეთ ის mixpanel.opt_in_tracking()-თან, როდესაც მომხმარებელი მიიღებს ანალიტიკის კატეგორიას თქვენს CMP-ში. SDK პატივს სცემს ამ პარამეტრს ყველა მომდევნო მოწოდებაში რეინიციალიზაციის საჭიროების გარეშე.

has_opted_out_tracking

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

EU რეზიდენტობის ოპცია

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

set_config({ ip: false })

გამორთავს IP მისამართის ჩაჭერას, ამცირებს თითოეული მოვლენის პერსონალური-მონაცემების კვალს. სასარგებლოა როგორც თავდაცვა-სიღრმის ზომა თანხმობის გაკეტვასთან ერთად.

ნაბიჯ-ნაბიჯ CMP ინტეგრაცია

ინტეგრაციის პატერნი, რომელიც საიმედოდ მუშაობს, არის Mixpanel-ის ინიციალიზაცია უარის მდგომარეობაში ნაგულისხმევად, შემდეგ კი მომხმარებლის ჩართვა, როდესაც ისინი მიიღებენ ანალიტიკის კატეგორიას CMP-ში.

1. ინიციალიზაცია გაუკეთეთ Mixpanel-ს უარის ნაგულისხმევით

მოიწოდეთ mixpanel.init(token, { opt_out_tracking_by_default: true }) რაც შეიძლება ადრე თქვენი აპლიკაციის ბუთსტრაპში. ეს ტვირთავს SDK-ს მაგრამ ხელს უშლის მას ნებისმიერი მოვლენის გაგზავნაში სანამ opt_in_tracking() არ მოიძახება.

2. დააკავშირეთ თანხმობის გადმოძახება

როდესაც CMP იწვევს თავის ანალიტიკის-კატეგორია-მიღებული მოვლენას, მოიწოდეთ mixpanel.opt_in_tracking(). რიგში მყოფი მოვლენები, რომლებიც ჩაჭერილი იყო უარის პერიოდში, ჩვეულებრივ უარყოფილია; თუ გჭირდებათ მათი შენარჩუნება, აუცილებლად კონფიგურირეთ SDK-ის რიგის ქცევა და მიიღეთ მცირე რისკი, რომ მოვლენები თანხმობამდელი პერიოდიდან გაიგზავნება თანხმობის შემდეგ.

3. გაუმკლავდით გაუქმებას

თუ მომხმარებელი მოგვიანებით გააუქმებს თანხმობას, მოიწოდეთ mixpanel.opt_out_tracking(). ეს აჩერებს შემდგომ მოვლენის ინგესტიას. ისტორიული მონაცემების სრული წაშლისთვის, აპლიკაცია დამატებით უნდა მოიწოდოს Mixpanel-ის წაშლის API-ს ან გამოიწვიოს წაშლის მოთხოვნა Mixpanel პროექტის UI-დან.

4. თავიდან აიცილეთ რეტროაქტიული იდენტობის გაერთიანება აშკარა თანხმობის გარეშე

გამორთეთ identify მოწოდების რეტროაქტიული გაერთიანების ქცევა გარდა იმ შემთხვევისა, როდესაც მომხმარებელმა დათანხმდა, რომ მათი წინა-იდენტიფიკაციის თვალიერება დაკავშირდეს მათ პროფილთან. Mixpanel-ის SDK ოპციები გამოაშკარავებს ალამს ამისთვის; კონსერვატიული ნაგულისხმევია "არა რეტროაქტიული გაერთიანება".

5. გამოიყენეთ EU რეზიდენტობის პროექტი EU ტრაფიკისთვის

პროექტებისთვის, სადაც EU რეზიდენტობა მნიშვნელოვანია, გადაამისამართეთ EU ტრაფიკი EU-რეზიდენტობის Mixpanel პროექტზე და აშშ/სხვა ტრაფიკი ცალკე პროექტზე. SDK უჭერს მხარს სხვადასხვა ტოკენების ჩატვირთვას მომხმარებლის აღმოჩენილი რეგიონის პირობითად.

გავრცელებული ხაფანგები

ოთხი ინტეგრაციის შეცდომა შეადგენს უმეტესობას ოდიტის დასკვნებისა Mixpanel განლაგებებზე.

Mixpanel-ის მკურნალობა როგორც გათავისუფლებული, რადგან ეს შიდა-გამოყენებაა

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

Autocapture-ის დატოვება ჩართულად ნაგულისხმევად

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

რეტროაქტიული იდენტობის გაერთიანების დავიწყება

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

EU რეზიდენტობის ვარაუდის ჰარდკოდირება

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

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

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

• იწყებს თუ არა Mixpanel უარში? დაადასტურეთ, რომ SDK ინიციალიზდება opt_out_tracking_by_default: true-თი და არცერთი მოვლენა არ ისვრის თანხმობამდე.
• იწვევს თუ არა ჩართვა სწორ CMP მოვლენაზე? დაადასტურეთ, რომ ანალიტიკის-მიღებული გადმოძახება მოიწოდებს opt_in_tracking()-ს, არა უფრო დამშვებ მოვლენას.
• აუცილებელია თუ არა Autocapture? თუ ის ჩართულია, დოკუმენტირება გააკეთეთ რატომ. თუ არა, გამორთეთ იგი.
• გამორთულია თუ არა რეტროაქტიული გაერთიანება? დაადასტურეთ, რომ იდენტიფიცირების მოწოდება არ ასოცირებს თანხმობამდელ ანონიმურ ქცევას ახლად იდენტიფიცირებულ პროფილებთან.
• არის თუ არა EU ტრაფიკი EU-რეზიდენტობის პროექტზე? დაადასტურეთ, რომ მარშრუტირების ლოგიკა აგზავნის EU ვიზიტორებს EU პროექტის ტოკენზე.
• ავტომატიზებულია თუ არა წაშლის მოთხოვნები? დაადასტურეთ, რომ DSAR მოთხოვნები იწვევს Mixpanel-ის წაშლის API-ს ვიდრე ხელით ბილეთს.

სად ჯდება Mixpanel თანხმობა-პირველ სტეკში

პროდუქტის ანალიტიკის პლატფორმები იკავებენ რეგულაციურ კატეგორიას, რომელსაც პროდუქტის გუნდები ხშირად უპირისპირდებიან — მათ სურთ იფიქრონ Mixpanel-ზე როგორც შიდა ინფრასტრუქტურაზე, არა როგორც მესამე მხარის თრექერზე. რეგულატორები არ ატარებენ ამ განსხვავებას, და ბოლო ორი წლის აღსრულების ქმედებებმა ნათელი გახადა, რომ ისინი არ გააკეთებენ. სწორი არქიტექტურა მკურნალობს Mixpanel-ს ზუსტად როგორც ნებისმიერ სხვა მესამე მხარის ანალიტიკის ზედაპირს: გააკეთეთ იგი თანხმობის უკან, გამოიყენეთ პლატფორმის მშობლიური ჩართვის პრიმიტივები კარიბჭის აღსასრულებლად, გადაამისამართეთ EU ტრაფიკი EU რეზიდენტობის ინფრასტრუქტურაზე, და გამორთეთ ფუნქციები (Autocapture, რეტროაქტიული იდენტიფიცირების გაერთიანება), რომლებიც აფართოებენ ოდიტის ზედაპირს პროპორციული ანალიტიკური სარგებლის გარეშე. სწორად გაკეთებულად, პროდუქტის გუნდები ინახავენ ფანელისა და შენარჩუნების მონაცემებს, რაც მათ სჭირდებათ, და იურიდიულ გუნდს ინახავს დოკუმენტაცია, რაც სჭირდება განლაგების დასაცავად ოდიტის ქვეშ.