gdpr
GDPR - Recording simple page views
<p>We are currently using google analytics to track our site.</p>

<p>The issue we now have with GDPR is we don't have a clear picture of our entrance pages. Our landing page data is messed up badly because the tracking cookies have to be blocked initially until the consent is given. In our case it's a soft opt-in on continual use.</p>

<p>So I was wondering. Can I add some in house code directly on the server to record landing page hits. only recording say the page name &amp; time. Maybe even a couple of element clicks.</p>

<p>This way no cookies are used and there is 0 chance of identifiable relational data being used other than reading the php session. Which doesn't count as UI.</p>

<p>And more importantly I don't need consent and can start getting the data I need right off the bat?</p>

<p>The so called "cookie law" is Article 5(3) of <a href="https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32002L0058:EN:HTML" rel="nofollow noreferrer">Directive 2002/58/EC</a>:</p>

<blockquote>
  <ol start="3">
  <li>Member States shall ensure that the use of electronic communications networks to store information or to gain access to information stored in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned is provided with clear and comprehensive information in accordance with Directive 95/46/EC, inter alia about the purposes of the processing, and is offered the right to refuse such processing by the data controller. This shall not prevent any technical storage or access for the sole purpose of carrying out or facilitating the transmission of a communication over an electronic communications network, or as strictly necessary in order to provide an information society service explicitly requested by the subscriber or user.</li>
  </ol>
</blockquote>

<p>So this does not only apply to cookies, but to any way to store or retrieve information on/from the equipment of the user.</p>

<p>When you use a PHP session, the <a href="http://php.net/manual/en/session.idpassing.php" rel="nofollow noreferrer">session ID</a> is stored in a session cookie or URL parameter. If a URL parameter is used, it is also stored on the equipment of the user, so the "cookie law" would also apply to that, but I am not sure about that. </p>

<p>The Article 29 Data Protection Working Party (Art. 29 WP) has written <a href="https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf" rel="nofollow noreferrer">Opinion 04/2012 on Cookie Consent Exemption</a>. It considers a session-ID to be exempted from the requirement of informed consent:</p>

<blockquote>
  <p>3.1 “User-input” cookies</p>
  
  <p>The term “user input cookies” can be used as a generic term to describe session cookies that are used to keep track of the user’s input in a series of message exchanges with a service provider in a consistent manner. These would be expected to be first party cookies typically relying on a Session-ID (a random temporary unique number) and expire when the session ends at the latest.</p>
  
  <p>First party user input session cookies are typically used to keep track of the user’s input when filling online forms over several pages, or as a shopping cart, to keep track of the items the user has selected by clicking on a button (e.g. “add to my shopping cart”).</p>
  
  <p>These cookies are clearly needed to provide an information service explicitly requested by the user. Additionally, they are tied to a user’s action (such as clicking on a button or filling a form). As such these cookies are exempted under CRITERION B. </p>
</blockquote>

<p>So basically, a PHP session ID cookie does not require consent.</p>

<p>However as soon as a session id is used for analytics, it is not exempted:</p>

<blockquote>
  <p>4.3 First party analytics</p>
  
  <p>Analytics are statistical audience measuring tools for websites, which often rely on cookies. These tools are notably used by website owners to estimate the number of unique visitors, to detect the most preeminent search engine keywords that lead to a webpage or to track down website navigation issues. Analytics tools available today use a number of different data collection and analysis models each of which present different data protection risks. A firstparty analytic system based on “first party” cookies clearly presents different risks compared to a third-party analytics system based on “third party” cookies. There are also tools which use “first party” cookies with the analysis performed by another party. This other party will be considered as a joint controller or as a processor depending on whether it uses the data for its own purposes or if it is prohibited to do so through technical or contractual arrangements.</p>
  
  <p>While they are often considered as a “strictly necessary” tool for website operators, they are not strictly necessary to provide a functionality explicitly requested by the user (or subscriber). In fact, the user can access all the functionalities provided by the website when such cookies are disabled. As a consequence, these cookies do not fall under the exemption defined in CRITERION A or B.</p>
  
  <p>However, the Working Party considers that first party analytics cookies are not likely to create a privacy risk when they are strictly limited to first party aggregated statistical purposes and when they are used by websites that already provide clear information about these cookies in their privacy policy as well as adequate privacy safeguards. Such safeguards are expected to include a user friendly mechanism to opt-out from any data collection and comprehensive anonymization mechanisms that are applied to other collected identifiable information such as IP addresses.</p>
  
  <p>In this regard, should article 5.3 of the Directive 2002/58/EC be re-visited in the future, the European legislator might appropriately add a third exemption criterion to consent for cookies that are strictly limited to first party anonymized and aggregated statistical purposes. First party analytics should be clearly distinguished from third party analytics, which use a common third party cookie to collect navigation information related to users across distinct websites, and which pose a substantially greater risk to privacy. </p>
</blockquote>

<p>So Art. 29 WP does not consider it a privacy risk under the conditions in the last two paragraphs. At least in some EU countries (<a href="http://wetten.overheid.nl/jci1.3:c:BWBR0009950&amp;hoofdstuk=11&amp;paragraaf=11.1&amp;artikel=11.7a&amp;z=2018-07-28&amp;g=2018-07-28" rel="nofollow noreferrer">Like the Netherlands</a>) you would be exempted from the requirement of informed consent because of that. </p>

<p>In your question you also mention you use "a soft opt-in on continual use". That is <a href="http://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=623051" rel="nofollow noreferrer">not sufficient</a> to obtain consent.</p>

<p>The ePrivacy directive (“cookie law”) requires consent when accessing or storing information on a user's device, unless that access is strictly necessary for a service explicitly requested by the user. This means you can use purely functional cookies, but otherwise need consent. The ePrivacy directive applies regardless of whether the cookies contain personal data.</p>
<p>On the other hand, processing of personal data falls under the GDPR. Since IP addresses are usually personal data, servers-side processing of access logs would be processing of personal data and would require a legal basis. But GDPR is more flexible than ePrivacy – instead of consent, a “legitimate interest” might be sufficient. Furthermore, GDPR does not apply to truly anonymous data, such as aggregate statistics. E.g. a classic page view counter would likely be out of scope for the GDPR.</p>
<p>So yes, you can do some server side data collection to augment your client-side analytics. You can likely collect some data without consent. The tricky question would be how much you can collect on the server. Whereas aggregate statistics like counts are likely fine, using additional data for analytics could bring ePrivacy back into play.</p>
<p>The GDPR also doesn't distinguish between client-side and server-side processing, indicating that you might be able to collect basic data for Google Analytics without consent. For example, the following flow might be ePrivacy- and GDPR-compliant:</p>
<ul>
<li>when the page loads, Google Analytics is also loaded</li>
<li>if cookies had previously been set, GA is initialized with a client ID from a cookie</li>
<li>otherwise, a random client ID is generated and held in a variable (not in a cookie)</li>
<li>this new client ID is used to send a pageview event</li>
<li>if the user accepts analytics cookies, the client ID is stored in a cookie so that a profile for that client ID can be created across later pageviews</li>
</ul>
<p>This hinges on the theory that the other information captured (like screen resolution) does not fall under ePrivacy. But since the temporary client ID is not persisted on the users' device until consent is given, pageview-level analytics are possible without consent. The consent is only necessary to capture session-level analytics.</p>
<p>(Of course, there are more general issues from both the legal and technical side: GA uses US servers which might no longer be legal in the wake of the 2020 Schrems II ruling, and adblockers are becoming increasingly popular which can heavily distort analytics on some websites.)</p>
