Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cookieless tracking in walled garden #970

Open
Christian-Lange-ext-deka opened this issue Mar 14, 2023 · 6 comments
Open

cookieless tracking in walled garden #970

Christian-Lange-ext-deka opened this issue Mar 14, 2023 · 6 comments

Comments

@Christian-Lange-ext-deka

Expected Behaviour

I can use alloy without cookies.
alloy can use a session mechanism that is provided by the caller.

Actual Behaviour

alloy sets cookies to track the user

Further Information

I'm not sure if this is the right place to ask for a feature, but please be kind and tell me where the right place is to request the feature when this one is wrong.
I want to explain the the request a little bit more. I'm working in the EU and the GDPR is strict in requesting a cookie banner when we set a non-technical-cookie. A tracking cookie is, as far as I know, a non-technical-cookie that needs a banner. I'm working in an environment where all users are logged in. There is no anonymous access. In such an environment we could use the session of the logged in user to identify him or his cohort (group he belongs to).
As far as I understand (https://experienceleague.adobe.com/docs/experience-platform/edge/web-sdk-faq.html) alloy use in all cases a cookie to track the user.

Some questions:

  1. Do you support or have plans to support other identifying mechanisms?
  2. Do you have a suggestion how to implement such a cookieless tracking mechanism?
  3. I've seen that cookies are handled by a cookieJar.js (https://github.com/adobe/alloy/blob/main/src/utils/cookieJar.js) would it be a good idea to use this point to inject own logic?

I'm grateful for all support and ideas from your site.

@jonsnyder
Copy link
Contributor

Before we can answer your questions I'd like to ask some clarifying ones. We do have support for First party device IDs (https://experienceleague.adobe.com/docs/platform-learn/data-collection/edge-network/generate-first-party-device-ids.html?lang=en). This system still results in an identity cookie though. There is some data that we store on the client. As you can see from the Web SDK FAQ you linked to, we store consent information, cluster information, and some additional information in the identity cookie. Where would you want this information to be stored? Local storage? Your own cookie?

@Christian-Lange-ext-deka
Copy link
Author

Thanks for the fast reply and the link.
We use already first party cookies (at least we have disabled the thirdparty cookies thirdPartyCookiesEnabled: false). For our purpose it should be enough to have the user session as identifying ID. We use keycloak as openid-connect implementation and have a state from site. I know it is not really comparable with a device ID but somehow a ID that is at least the same for that session. In the best case we should not need a local storage the store anything and we can reuse some ID we already have.
Does it sound reasonable?
I'm looking a little bit in the matomo corner (https://matomo.org/faq/new-to-piwik/how-do-i-use-matomo-analytics-without-consent-or-cookie-banner/) that support some kind of cookieless tracking. It would be nice to have such kind of tracking in the adobe universe. Maybe it leads to some kind of reduced information, but in favor for more data in general because no cookie banner needed. We are in a b2b case, and we just need the tracking on our application and do not need to connect this information with other sites. We just want to check aspects of the UX and see where problems are.

@Christian-Lange-ext-deka
Copy link
Author

okay, the short cut was using (how you proposed) to use the localStorage. Quick and dirty - main...Christian-Lange-ext-deka:alloy_cookieless:main
I know this makes technically not much difference, but at least now cookie banner is required for that. I would expect that for GDPR compliance the user must still accept this.
From your perspective would be okay to save the cookie-data in localStorage (with some more logic to handle attributes)?

@jonsnyder
Copy link
Contributor

Keep in mind that this will break when using first party data collection. In first party data collection, the cookies are set directly by Adobe experience edge servers. Additionally, when making requests to first party servers, Web SDK assumes the cookies will be included in the request.

@Christian-Lange-ext-deka
Copy link
Author

Is a good point. At the moment we are still in communication with our legal department if consent-less tracking is possible at all. In Germany we have additionally to the GDPR a TTDSG that could prevent a consent-less tracking from the frontend at all. Know we are evaluating the value of a backend-based tracking. I know that alloy is a frontend-tool but is there a java-based tool to use tracking too? I know that the amount of information in the backend is reduced, but maybe it is better to have some information than nothing.

@jonsnyder
Copy link
Contributor

There is a network server API that you can call from Java. see https://experienceleague.adobe.com/docs/experience-platform/edge-network-server-api/overview.html?lang=en

We do not have server side SDKs for this API though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants