Το πρόβλημα των διπλών banners

Πολλές εφαρμογές είναι εν μέρει native και εν μέρει web. Ένα παιχνίδι εμφανίζει το κατάστημα, τις ειδήσεις ή τις σελίδες βοήθειάς του σε WebView· μια εφαρμογή χρησιμότητας αποδίδει άρθρα από τον ιστότοπό της· μια υβριδική εφαρμογή τυλίγει το μεγαλύτερο μέρος της διεπαφής της σε web περιεχόμενο. Κάθε πλευρά έχει τον δικό της μηχανισμό συναίνεσης: η native εφαρμογή χρησιμοποιεί ένα in-app CMP ή SDK και οι ιστοσελίδες φορτώνουν ένα web CMP. Αν δεν συνδεθούν, ο χρήστης ερωτάται δύο φορές, οι επιλογές που γίνονται σε ένα σημείο αγνοούνται στο άλλο, και τα αιτήματα διαφημίσεων από το εσωτερικό του WebView φεύγουν με λάθος σήματα.

Αυτός ο οδηγός καλύπτει πώς να κάνετε τη native και τη web συναίνεση να συμφωνούν, ώστε οι χρήστες να απαντούν μία φορά και κάθε αίτημα διαφήμισης να φέρει την ίδια απόφαση.

Πού αποθηκεύει τη συναίνεση κάθε πλευρά

Native

Το IAB TCF καθορίζει πώς ένα in-app CMP αποθηκεύει τη συναίνεση: στο NSUserDefaults στο iOS και στα SharedPreferences στο Android, με τυποποιημένα κλειδιά όπως IABTCF_TCString, IABTCF_gdprApplies και IABTCF_PurposeConsents. Τα ad SDKs διαβάζουν απευθείας αυτά τα κλειδιά. Το IAB GPP ορίζει παρόμοια κλειδιά με πρόθεμα IABGPP_, όπως το IABGPP_HDR_GppString.

Web

Ένα web CMP συνήθως αποθηκεύει την απόφασή του σε first-party cookies ή local storage για το domain του ιστότοπου και την εκθέτει μέσω των συναρτήσεων JavaScript __tcfapi και __gpp. Τα ad tags στη σελίδα καλούν αυτές τις συναρτήσεις, όχι την native αποθήκευση.

Το κενό

Τα WebViews έχουν δικό τους χώρο cookies και αποθήκευσης, ξεχωριστό από το πρόγραμμα περιήγησης της συσκευής και ξεχωριστό από τις native προτιμήσεις της εφαρμογής. Στο iOS, ένα WKWebView που χρησιμοποιεί μη μόνιμο data store ξεχνά τα πάντα όταν κλείσει. Τίποτα δεν ρέει ανάμεσα στις δύο πλευρές αν δεν το φτιάξετε.

Επιλέξτε μία πηγή αλήθειας

Η πρώτη απόφαση είναι ποια πλευρά κατέχει τη συναίνεση. Για τις περισσότερες εφαρμογές η απάντηση είναι το native CMP, επειδή:

• Εκτελείται πρώτο, πριν ανοίξει οποιοδήποτε WebView.
• Τα native ad SDKs, που συνήθως αποφέρουν τα περισσότερα έσοδα, διαβάζουν native αποθήκευση.
• Στο iOS, μπορεί να συντονιστεί με το αίτημα App Tracking Transparency.

Η προσέγγιση web-first μπορεί να έχει νόημα για υβριδικές εφαρμογές των οποίων ολόκληρη η διεπαφή είναι web περιεχόμενο, αλλά τότε πρέπει να γράψετε την απόφαση πίσω στη native αποθήκευση για τα native SDKs.

Μεταφορά της native συναίνεσης στο WebView

Όταν η πηγή αλήθειας είναι το native, το WebView πρέπει να βλέπει την ίδια απόφαση. Συνηθισμένα μοτίβα:

1. Εισαγάγετε μια υλοποίηση του __tcfapi. Πριν εκτελεστούν τα scripts της σελίδας, εισαγάγετε ένα μικρό script που ορίζει το __tcfapi (και το __gpp αν χρειάζεται) και απαντά στις κλήσεις με το TC string και τις τιμές που διαβάστηκαν από τη native αποθήκευση. Τα ad tags στη σελίδα λαμβάνουν τότε τη native απόφαση μέσω του τυπικού API.
2. Καταστείλετε το web banner. Ρυθμίστε το web CMP να παραμένει κρυφό όταν η σελίδα φορτώνεται μέσα στην εφαρμογή σας, για παράδειγμα με βάση μια παράμετρο query ή ένα προσαρμοσμένο token user agent που ελέγχετε. Διαφορετικά ο χρήστης βλέπει δεύτερο banner.
3. Περάστε το string κατά τη φόρτωση. Ορισμένα web CMP μπορούν να δεχτούν ένα υπάρχον string συναίνεσης κατά την αρχικοποίηση και να το υιοθετήσουν. Ελέγξτε την τεκμηρίωση του web CMP σας για τις υποστηριζόμενες μεθόδους.

Όποιο μοτίβο κι αν χρησιμοποιήσετε, βεβαιωθείτε ότι οι εισαγόμενες τιμές ενημερώνονται όταν ο χρήστης αλλάζει την επιλογή του στην native οθόνη ρυθμίσεων, όχι μόνο στην επόμενη εκκίνηση της εφαρμογής.

Επιστροφή της web συναίνεσης στο native

Αν οι χρήστες μπορούν να αλλάξουν τη συναίνεση μέσα στο WebView, για παράδειγμα μέσω μιας σελίδας ρυθμίσεων απορρήτου, η εφαρμογή πρέπει να το μάθει. Χρησιμοποιήστε μια γέφυρα JavaScript: έναν message handler στο iOS ή μια διεπαφή JavaScript στο Android. Η web πλευρά ακούει με __tcfapi('addEventListener', ...) και στέλνει το νέο string στον native κώδικα, ο οποίος γράφει τα τυπικά κλειδιά. Επικυρώστε την είσοδο από το WebView πριν τη γράψετε· δεχτείτε μηνύματα μόνο από το δικό σας περιεχόμενο.

Διαφημίσεις μέσα σε WebViews

Οι διαφημίσεις που αποδίδονται σε ένα WebView είναι web διαφημίσεις. Διαβάζουν τη συναίνεση από τη σελίδα, όχι από τη native αποθήκευση, εκτός αν το ad SDK παρέχει τρόπο σύνδεσης των δύο. Το Mobile Ads SDK της Google, για παράδειγμα, προσφέρει ένα API για καταχώριση WebViews ώστε οι διαφημίσεις μέσα σε αυτά να μπορούν να χρησιμοποιούν σήματα από την εφαρμογή· ελέγξτε την τρέχουσα τεκμηρίωση για το SDK σας. Σε κάθε περίπτωση, επιβεβαιώστε με δοκιμή ότι τα αιτήματα διαφημίσεων από το WebView φέρουν το ίδιο TC ή GPP string με τα native αιτήματα διαφημίσεων.

Λίστα ελέγχου δοκιμών

• Νέα εγκατάσταση: ένα αίτημα συναίνεσης, όχι δύο.
• Απορρίψτε όλα στο native CMP, ανοίξτε ένα WebView, επιθεωρήστε τα αιτήματα διαφημίσεων: το string πρέπει να αντικατοπτρίζει την απόρριψη.
• Αλλάξτε τη συναίνεση στις native ρυθμίσεις, επιστρέψτε σε ένα ανοιχτό WebView: η σελίδα πρέπει να βλέπει τη νέα απόφαση.
• Αν υπάρχουν web ρυθμίσεις, αλλάξτε τη συναίνεση εκεί και επιβεβαιώστε ότι τα native κλειδιά ενημερώνονται.
• Τερματίστε και επανεκκινήστε την εφαρμογή: οι αποφάσεις διατηρούνται και στις δύο πλευρές.
• Δοκιμάστε σε iOS και Android, αφού η αποθήκευση του WebView συμπεριφέρεται διαφορετικά σε καθένα.

Βασικά συμπεράσματα

• Η native συναίνεση και η συναίνεση του WebView ζουν σε ξεχωριστούς χώρους αποθήκευσης και δεν συγχρονίζονται από προεπιλογή.
• Επιλέξτε μία πηγή αλήθειας· για τις περισσότερες εφαρμογές είναι το native CMP.
• Εκθέστε τη native συναίνεση στο web περιεχόμενο μέσω ενός εισαγόμενου __tcfapi ή __gpp και κρύψτε το web banner.
• Χρησιμοποιήστε μια γέφυρα JavaScript για να στέλνετε τις αλλαγές του web πίσω στη native αποθήκευση.
• Ελέγξτε ότι τα αιτήματα διαφημίσεων από WebViews φέρουν το ίδιο string συναίνεσης με τα native.