YES. Our CMP_ID is 2. You can consult this page to check our status :https://iabeurope.eu/cmp-list/
NO. Using the backoffice, you can add as many purposes you need. We also support higly sensitive purpose like Geolocation for advertising purpose. Check the iOS and Android section to learn more.
YES and NO. Using our backoffice, you can customize almost everything. Some things are not possible due to legal reasons but also to the way we understand the GDPR and the upcoming ePrivacy regulation. As an example, it's not possible to force the status of our switchs. This is something that will never pass a check from any European Regulator.
YES .. but not for long. The very last comments from the regulators tell the market that all "artificial consents" will not be legal anymore very soon. As a CMP, we don't support scroll as a valid event. But using our callback, you can decide to still use this events to fetch consents from your users.
SFBX Official position on this: We believe that, as a market, we need to replace getting consents using by scroll and click by other ways. It's not aligned with the core of the GDPR.
If you decide to carry on using scroll 'like events, we strongly advice you to test without scroll in order to do statistics on your consent rate.
NO. Just refresh your page in your browser and that's it. It's a matter of only hundreds of ms to populate a new build of our CMP WebApp.
Well, CMPs are the new comers in the market field so new specific words too.
By using our CMP, you can control whether you want to use a banner to obtain consent in a first place. This banner is generally positioned at the bottom of the screen. What we call the notice, is the real visible part of the CMP, i.e. where the Internet user or mobile user will make his choices. Sometimes we call it WebApp to make a clear difference between the Web perimeter and in-App.
YES. This is the recipe : Put a hard wall; meaning that the user have no choice to accept or configure. Blur the background. Don't hezitate to put a very large window. Change the configure button to a link. And put a lot of text before the button. Do not use a font size that is too large. Put a cross in the top right that is wired with an acceptance event. Do not forget to add an event wired to a 100px event and/or a click in the page. That's it, you just finished to cook something that will give you a > 99% consent rate.
But in return, you will see your bounce rate increase a lot. By the way it depends a lot of the shape and structure of your audience. Some websites are less impacted. But in case of control by the regulator, the is a lot lot chances that they don't see that as a valid way of getting consent. And the doctrine is simple : no consent, no right to use the data. And the vendors connected to the CMP may loose the right to process all the data already collected as they rely on consent.
@sfbx, we think that in order to cook something more clever, we all need to take into account : The user in first place, because afterall, we ask his/her data. But we also need to keep an eye on the reactions of the European ICOs ( and escpially the French CNIL) to build a balanced way of getting consents that :
Respect the user
Preserve as mush possible your turn over
Respects the spirit of the GDPR, and the comments of regulators.
GDPR aims to protect personal data for european users. You must display the CMP for all european country. For all other countries, there is no need to display the CMP, for the moment.
AppConsent manages translations of 4 default languages in the Backoffice, but this number can be extended to all EU languages if needed.
As we can't know the user nationality, AppConsent CMP translation is based on the language used by the user on his browser or device:
For the web desktop version, the CMP is configured to be displayed in the language configured in the user's browser. For example, if the user is in the US but his browser is configured in French, the CMP will be displayed in French.
For mobile and mobile web version, the CMP is configured to be displayed in the language configured in the device.
The consents are kept during 12 months. After that the user must give his consent again.
As already mentioned above, we use proprietary UX approaches to understand user behavior when faced with CMP-type choices. But also what they understand about the GDPR, what they expect. Focus groups, interviews, guerrilla tests. We do a lot of work on these topics. This work allows us to obtain consent rates that converge towards the maximum expected, including in frameworks that will be constrained by regulators. Example: Refuse/Accept button instead of Configure/Accept.
You will get Consent Rate, amount of notice filled , consent-out and mixed consent in/out. A mixed consent occurs when a user didn't accept or deny the full purposes but customize his/her choices. In a very soon release, you will get the Withdraw - rate, meaning the amount of users that change their mind and no longer want to share his/her data. ( We already compute this, it s simply not displayed yet as a KPI in the dashboard).
We also measure the bounce rate. Even if it's not a directly releated privacy-cmp KPIs, you should follow closely this KPIs.
We will add more KPIs but only if it makes sens.
YES. In each contract, you some days provisionned to assist you technicaly. We are not lawyer and we don't act as DPO. Never. But we offers work force and tools ( like APIs) in order to help you to proove that you have consents for your users.
Since the very first day, we use blockchain technologie to proove consent. Begining of 2020, we switched from Hyperledger to Chainsaw, our proper blockchain.
99.99%. We believe as we are directly responsible for your turn over and the confort of your end-users, we have no alternative to offer this high standard of SLA.
We prefer to act as a member of the team rather than protect ourselves behind weaker SLAs. With this objective in mind, this has led us to put in place a whole battery of internal procedures, countermeasures in order to be able to fulfil such a promise.
SFBX was founded by two people acting in the data and adTech companies for a wild. We see 3rd cookies efficacity and stability declining almost every day since a while. Thus, one of our first feature was to build a work-around to this. So we use LocalStorage in order to store consent status and cache informations to speed up the CMP response time. More over, the entire plateforme is ID agnostic, meaning that we are ready for common login initiatives and using CRM IDs. We are even capable to do web2app consent Propagation.
There is two main kind of blockchain: Public and Private. It's true that Public blockchain raise many issues regarding GDPR/ePrivacy, espacially when you need to honor the right to be forgetten. As blockchain as built to never forget something, it's a paradox.
But we use Private Blockchain. Meaning that Data Controller is not spread into the wild using nodes that we have not under control. All the nodes are running @SFBX. We control de consensus, we control the participants. We control our ledger. And we never, ever store informations into our ledgers, we only store the proofs. And it makes a huge difference.
More over, this kind of architecture is preparing us to the futur of Data. At SFBX, we are convinced that the data can't no more circulate without weither a consent or a legal base attached, tied to this Data. And in order to build the pipeline that will sustain this, private blockchain are very efficient.
We are working hard since two years to raise the bar of the scalability of our blockchain stack.
We process right now, in production, thousands of transaction per second. This mean that when a end-user give his/her consent, the proof of consent is available some ms after.
If you have any further questions, send us an email to [email protected] and we will be happy to answer you and certainly add your question to this page.