Cookie Policy

Last updated: 27 May 2026

Controlling language. This document is published in English and translated into one or more additional languages for convenience. In case of conflict or ambiguity between language versions, the English version prevails.

#1. Introduction

This Cookie Policy explains how JJ Online GmbH ("we", "us", or "our"), operating ProductLog at https://productlog.dev (the "Website"), uses cookies and similar tracking technologies on the Website itself.

This policy covers what we set on productlog.dev: the marketing site, the authenticated admin dashboard, the public customer-facing changelog / feedback / roadmap / survey boards under productlog.dev/cl/…, /feedback/…, /roadmap/…, /s/…, the knowledge base under productlog.dev/kb/…, and the same surfaces when published under a Workspace Operator's custom domain (for example, changelog.theircompany.com). It does not cover any future embeddable changelog widget that runs on the Workspace Operator's own customer-facing website — that widget, when it ships, will be documented separately.

This policy should be read alongside our Privacy Policy.

#2. What counts as a "cookie" here

§ 25 TDDDG (the German implementation of the ePrivacy Directive (Directive 2002/58/EC), Art. 5 (3)) covers any "storage of information on a terminal equipment, or the gaining of access to information already stored on it". This policy therefore treats the following technologies equivalently:

• HTTP cookies — text values written to your browser's cookie storage
• Local storage (localStorage) — key-value data persisted in your browser until you clear it
• Session storage (sessionStorage) — key-value data persisted only for the current tab session
• Web beacons / pixels — transparent images embedded in pages (and, where applicable, emails) to detect opens or loads

We refer to all of these as "cookies" throughout this document.

Server-side reads of request metadata (IP address, User-Agent, headers the browser voluntarily transmits in the HTTP request) are not covered by this Cookie Policy. They are not "storage of information on, or access to information already stored on, terminal equipment" within the meaning of § 25 TDDDG. Their lawfulness is assessed under Art. 6 GDPR only and is described in § 8 below.

#3. Categories we use

We classify cookies using the four categories applied by German Datenschutzaufsichtsbehörden (DPAs):

• Strictly Necessary (Technisch notwendig) — required for the Website to function: authentication, session continuity, two-factor flow, security, persisted UI state inside the authenticated dashboard, anti-double-vote enforcement on public boards. Set without consent under § 25 Abs. 2 Nr. 2 TDDDG ("strictly necessary to provide the telemedia service expressly requested by the user").
• Functional (Funktional) — UI preferences and opt-in convenience features beyond what is strictly necessary. (We do not currently use Functional cookies on productlog.dev — see § 4.)
• Analytics (Analyse) — page-view or behavioural measurement. (We do not currently use Analytics cookies on productlog.dev — see § 4.6.)
• Marketing (Marketing) — affiliate attribution, advertising, remarketing. (We do not currently use Marketing cookies on productlog.dev — see § 4.6.)

#4. Cookies we use

The table below lists every cookie and localStorage / sessionStorage entry we set or read on this Website.

#4.1 First-party cookies — HTTP cookies set by the ProductLog Next.js frontend

These two cookies are set client-side by the Next.js application so that the Next.js middleware (which runs at the edge before the React app loads) can make routing decisions, and so that team-invitation flows can persist a short-lived token across page navigations.

Name	Purpose (plain language)	Storage	Duration	Category	Legal basis (§ 25 TDDDG / Art. 6 GDPR)
prodlog_token	Mirrors your JWT access token so that the Next.js middleware can decide whether to redirect you to the sign-in page before the React app loads.	HTTP cookie (Path=/, SameSite=Lax; today not HttpOnly, not Secure — see § 8.4 (f) of the DPA for the disclosed product-roadmap remediation)	Browser session (no Max-Age)	Strictly Necessary	§ 25 Abs. 2 Nr. 2 TDDDG · Art. 6 (1)(b) GDPR
auth_token	A short-lived authentication token used only while you are clicking through a team-invitation link. Set on /accept-invitation/[token].	HTTP cookie (Path=/, SameSite=Lax; today not HttpOnly, not Secure — same remediation pipeline as prodlog_token)	7 days (Max-Age=604800)	Strictly Necessary	§ 25 Abs. 2 Nr. 2 TDDDG · Art. 6 (1)(b) GDPR

The backend API sets no HTTP cookies of its own. The API is fully stateless JWT — no Set-Cookie headers on API responses, no framework session cookie, no separate CSRF cookie.

#4.2 First-party storage in the authenticated admin dashboard

These entries are written by the Next.js dashboard application at productlog.dev/dashboard/… after you have signed in. They store JWT credentials and UI preferences and are classified as Strictly Necessary under § 25 Abs. 2 Nr. 2 TDDDG — they are set only inside the service you actively requested by signing in, and the dashboard cannot function without them.

Name	Purpose	Storage	Duration	Category
token	Your JWT access token, sent in the Authorization: Bearer header on every API call. Mirrors prodlog_token (the cookie) so both the React app and the Next.js middleware can see it.	localStorage	Until sign-out or token expiry	Strictly Necessary
prodlog_auth	A snapshot of your authentication state (your name, email, avatar URL, role, two-factor flag, and organization details) so the dashboard can render the signed-in shell on reload without an extra API round trip.	localStorage	Until sign-out	Strictly Necessary
productlog-ui	UI preference for the dashboard (currently only: sidebar collapsed / expanded).	localStorage	Until you clear browser storage	Strictly Necessary
prodlog_current_project_id	Remembers which project you had selected so you land in the same context on next sign-in.	localStorage	Until you clear browser storage or switch	Strictly Necessary
2fa_partial_token	A short-lived intermediate token issued by the backend after step 1 of two-factor sign-in, used only to authorise step 2 (the 2FA challenge). Cleared after successful verification.	sessionStorage	Browser session (cleared when you close the tab)	Strictly Necessary

#4.3 Public boards (/cl/…, /feedback/…, /roadmap/…, /s/…)

The public customer-facing boards — where visitors can read changelogs, vote on feedback items, react to entries, post comments, and answer surveys without an account — set no cookies and no localStorage or sessionStorage entries in the visitor's browser.

Anti-double-vote, anti-double-reaction, and anti-double-survey-response enforcement is performed server-side by computing a SHA-256(IP | User-Agent) fingerprint hash and storing it alongside the vote / reaction / comment / response. Nothing is read from or written to the visitor's terminal for this purpose; the processing is purely server-side and is therefore outside the scope of § 25 TDDDG. See § 8 below.

#4.4 Marketing site and knowledge base

No first-party localStorage, sessionStorage, or non-essential cookies. The HelpCanvas chat widget is loaded on these surfaces (and indeed on every productlog.dev surface) — see § 4.5.

#4.5 Third-party scripts — HelpCanvas chat widget

The only third-party script loaded on productlog.dev is the HelpCanvas chat widget, a sister product also operated by JJ Online GmbH (same Controller, not an Art. 28 Sub-processor).

Loaded on	Provider	What it does	Category	Storage / network exposure
Every page of productlog.dev (loaded asynchronously after page interactivity)	HelpCanvas (sister product of JJ Online GmbH)	In-app chat widget for visitor support (also disclosed in the DPA Annex C.3 and the Privacy Policy § 5.3).	Functional / Strictly Necessary if argued as support tooling	First-party-to-productlog.dev storage that the widget writes on interaction (e.g. its own consent record, an opaque conversation identifier). The script asset itself is fetched from the HelpCanvas origin, which exposes the visitor's IP address and User-Agent to that origin.

Pre-consent loading — disclosed honestly. The HelpCanvas widget is currently loaded on every productlog.dev route, including the marketing site, the authenticated dashboard, all public boards (including under a Workspace Operator's custom domain), and the knowledge base, without a consent gate. Because HelpCanvas is operated by the same Controller as ProductLog (JJ Online GmbH), this is not a cross-controller transfer — but § 25 TDDDG still applies to any storage the widget writes on the visitor's terminal regardless of who the recipient is. Whether a § 25 Abs. 1 TDDDG consent gate is required for the widget depends on what storage the widget actually sets in production. The product-level remediation options are: (a) deploy the Datriva CMP banner on productlog.dev and gate the widget on Functional consent, (b) lazy-load the widget on visitor click only, or (c) confirm in writing that the widget sets only Strictly-Necessary storage and treat the load as service-necessary under § 25 Abs. 2 Nr. 2 TDDDG. The decision among (a), (b), (c) is a pending product item disclosed here under Art. 5 (1)(a) GDPR transparency.

#4.6 What we deliberately do not load

For the avoidance of doubt — and verified against the production codebase on 2026-05-26 — we do not load any of the following on productlog.dev:

Google Analytics / GA4 / Google Tag Manager, Meta / Facebook Pixel, LinkedIn Insight Tag, X (Twitter) Pixel, Reddit Pixel, TikTok Pixel; Plausible, Matomo, Fathom, Umami; PostHog, Mixpanel, Segment, Amplitude; Hotjar, FullStory, LogRocket, Microsoft Clarity, Smartlook; Sentry browser SDK; Intercom, Crisp, Drift, Tawk (HelpCanvas is our chat); Optimizely, VWO, LaunchDarkly, Google Optimize; Google Fonts CDN; Stripe.js on first-party pages (see § 4.7); PayPal SDK (we do not accept PayPal); affiliate-attribution SDK.

Our internal in-app analytics are server-side only — they record events posted to the backend by authenticated API calls, not by any browser tag, and are therefore outside the scope of § 25 TDDDG. See § 8 below for the legal-basis analysis of those server-side reads.

#4.7 Payments — Stripe is server-side only

When you subscribe to a paid ProductLog Subscription, you are redirected to checkout.stripe.com. Stripe sets its own first-party cookies on checkout.stripe.com during that checkout flow, governed by Stripe's own Cookie Notice. No Stripe.js loads on productlog.dev and no Stripe cookies are set on the productlog.dev domain.

#4.8 Email — broadcast-email tracking vs transactional emails

ProductLog dispatches two distinct categories of email through AWS SES eu-central-1 (Frankfurt), with different tracking postures:

Transactional emails — no open or click tracking. Account-confirmation, password-reset, team-invitation, security-alert, and other transactional emails JJ Online sends to Workspace Operators contain no open-tracking pixels and no click-rewriting redirector. Links in these emails are plain https://productlog.dev/… URLs and do not pass through a tracking redirector.

Broadcast emails to End-Subscribers — open and click tracking, on the Workspace Operator's instruction. When a Workspace Operator publishes a changelog entry and sends a broadcast to its End-Subscribers (who have completed double opt-in to that subscription), the broadcast email includes:

• a 1×1 open-pixel embedded in the message; when the End-Subscriber's email client loads the pixel, the load registers an analytics-event record associated with that broadcast and increments the broadcast's open count
• click rewriting — outbound links in the broadcast are wrapped through a redirector that logs an analytics-event record on click and increments the broadcast's click count before redirecting the End-Subscriber to the target URL

This is tracking storage on the End-Subscriber's terminal within the meaning of § 25 Abs. 1 TDDDG (the open-pixel load is itself an information-access event from the End-Subscriber's mail client). The lawful basis is Art. 6 (1)(a) GDPR — the End-Subscriber's consent, collected by the Workspace Operator via the double-opt-in flow, together with the Workspace Operator's Art. 6 (1)(f) GDPR legitimate interest in measuring the effectiveness of the broadcast on its own list. The Workspace Operator is the Controller of this processing; JJ Online acts as Processor under the DPA. The Workspace Operator is responsible for ensuring that the double-opt-in confirmation captures consent to receive the broadcast and for disclosing the open / click tracking in the Workspace Operator's own Art. 13 GDPR notice presented at subscription.

The aggregated open / click counts on each broadcast are visible to the Workspace Operator in the dashboard; the underlying analytics-event records expire under the 90-calendar-day retention target documented in Privacy Policy § 11 (subject to the disclosed purge-provisioning gap).

#5. Third-party cookies — disclosure

The third-party script disclosed in § 4.5 is HelpCanvas, a sister product of JJ Online GmbH. Because the Controller is the same, the relationship is not a third-party transfer under GDPR; the data flow is documented for transparency. HelpCanvas's own privacy practices are governed by its Privacy Policy.

Transfers of Personal Data to recipients outside the EEA — where they occur — are governed by the appropriate Chapter V GDPR mechanism (adequacy decision, Standard Contractual Clauses) as described in our Privacy Policy § 15.

#6. Cookie consent

#6.1 Current consent posture

A cookie banner is not currently deployed on productlog.dev. This is disclosed honestly here under Art. 5 (1)(a) GDPR transparency:

• The cookies and storage we set ourselves (§§ 4.1–4.3) are all Strictly Necessary under § 25 Abs. 2 Nr. 2 TDDDG and require no consent
• The only non-first-party script loaded is the HelpCanvas widget (§ 4.5), which is operated by JJ Online GmbH — the same Controller as ProductLog. Whether that widget needs a separate § 25 Abs. 1 TDDDG consent gate is a pending product decision disclosed in § 4.5 above
• Broadcast-email open-pixel and click-rewriting tracking (§ 4.8) is governed by the End-Subscriber's double-opt-in consent collected by the Workspace Operator, not by a productlog.dev cookie banner

When we deploy a banner on productlog.dev, it will be the Datriva CMP (also a JJ Online product) and will (consistent with the pattern used across the other JJ Online products and required by EDPB Guidelines 03/2022 on dark patterns and § 25 TDDDG):

• Appear before any non-essential cookie or third-party network call is made
• Present any consent-required categories (Functional, Analytics, Marketing) as opt-in only, with each category unticked by default — no pre-ticked boxes (Planet49, CJEU C-673/17)
• Offer Accept all, Reject all, and Customize with equal visual weight, in the same number of clicks
• Record your choice in a first-party consent record
• Be reopenable via a persistent "Cookie Preferences" link in the footer, in line with Art. 7 (3) GDPR (withdrawal as easy as giving consent)

#6.2 Withdrawing consent — as easy as giving it (when consent applies)

Art. 7 (3) GDPR requires that withdrawing consent be as easy as giving it. Per EDPB Guidelines 05/2020 on consent (§ 117), parity here means the same medium and the same number of steps as the original opt-in. Once the banner is deployed and where consent applies, the Cookie Preferences link in the marketing-site footer will be the sole Art. 7 (3) parity route. Two further routes will be available for convenience but are not equivalent to the original opt-in:

• Cookie Preferences link (Art. 7 (3) parity route). A persistent "Cookie Preferences" link in the footer of every marketing page; clicking it reopens the Datriva banner so you can change any category — or reject all non-essential cookies — in the same number of clicks it took to accept them
• Email to [email protected]. Additional route, not equivalent. We will record and action the withdrawal manually within the Art. 12 (3) GDPR timeframe
• Clearing cookies in your browser. Additional route, not equivalent. Clearing also clears any locally-stored consent record so the banner reappears on your next visit; the steps involved are not equivalent to the original opt-in mechanism

#6.3 Effect of withdrawal

Non-essential cookies and storage stop being set immediately on withdrawal. Non-essential entries already stored on your device are cleared at the next page load (or, for session-scoped entries, when you close the tab). Our consent record is updated with a withdrawal timestamp so we can evidence the change under the controller's burden of proof at Art. 7 (1) GDPR.

Consent record retention (when the banner is deployed). We will retain the consent record (acceptance timestamp, category selections, and any subsequent withdrawal timestamp) for 3 years from the most recent of those events, as evidence of compliance with Art. 7 (1) GDPR. After that period the consent record is deleted; if you revisit the Website afterwards, the banner re-prompts you for fresh consent.

Withdrawal does not affect the lawfulness of processing carried out on the basis of your consent before withdrawal (Art. 7 (3) GDPR, second sentence).

#6.4 Consent renewal

Where you have not used the Website for an extended period, or where we add new cookie purposes that fall outside your existing consent, we will ask you again. Consent is refreshed at most every 12 months in line with EDPB Guidelines 05/2020 on consent.

#6.5 Global Privacy Control (GPC) and Do Not Track (DNT)

• GPC will be honoured. Once the Datriva CMP banner is deployed on productlog.dev, where your browser transmits the Sec-GPC: 1 signal on its request to the marketing site, we will treat it as a valid expressed refusal of consent for the Functional, Analytics, and Marketing categories — consistent with the CNIL's published position that GPC is a valid mechanism for refusing consent. The banner will record this as a "Reject all" decision and will not load non-essential third-party scripts.
• DNT is not honoured. The DNT: 1 header is deprecated and lacks a settled regulatory interpretation; we therefore do not treat it as an instruction either way and do not act on it.

#7. Legal basis — § 25 TDDDG and Art. 6 GDPR

Two distinct legal layers apply to the cookies in this policy. Both must be satisfied:

Layer 1 — Setting / reading the cookie itself. Governed by § 25 TDDDG. Either:

• the cookie is strictly necessary to provide the telemedia service you requested (§ 25 Abs. 2 Nr. 2 TDDDG) — no consent required; or
• the cookie requires your prior, explicit consent (§ 25 Abs. 1 TDDDG) — collected via the banner.

Layer 2 — Processing the Personal Data the cookie touches. Governed by Art. 6 GDPR. The applicable basis is shown per cookie in § 4 above and depends on what the data is used for: Art. 6 (1)(a) GDPR (consent), (b) (contract), (c) (legal obligation), or (f) (legitimate interest).

A single cookie therefore has a § 25 TDDDG basis for being set and an Art. 6 GDPR basis for the data processing that follows. Strict-necessity under § 25 Abs. 2 Nr. 2 TDDDG does not automatically give a GDPR basis for further processing — these are independent assessments.

#8. Server-side reads of IP and User-Agent

Separate from browser-stored cookies, ProductLog reads server-side request metadata for two distinct purposes, both with non-consent legal bases under § 25 Abs. 2 Nr. 2 TDDDG and Art. 6 GDPR:

• Security and abuse prevention. Your IP address is read for rate-limiting on sign-in (5 failed attempts / 5 minutes / IP), sign-up (3 attempts / 15 minutes / IP), forgot-password, the contact form, and public-board actions. Processed under Art. 6 (1)(b) GDPR (contract — operating an authenticated service) and Art. 6 (1)(f) GDPR (legitimate interest in account integrity and abuse prevention).
• Anti-double-vote / anti-double-reaction / anti-double-survey-response enforcement on public boards. When a visitor casts a vote, posts a reaction, comments, or answers a survey on a public board, the backend computes a SHA-256(IP | User-Agent) hash and persists that hash alongside the vote / reaction / comment / response. This prevents the same visitor from voting twice. The hash is processed under § 25 Abs. 2 Nr. 2 TDDDG as strictly necessary to deliver the one-vote-per-visitor action the visitor explicitly invoked, with the Art. 6 GDPR basis being Art. 6 (1)(b) (performance of the implicit contract for the requested action) and Art. 6 (1)(f) (legitimate interest in preventing roadmap manipulation).

These server-side reads are described in the Privacy Policy under "Server-side request metadata" and "Public-board visitor metadata". They are not within the scope of § 25 TDDDG because nothing is read from or written to your terminal — the processing is purely server-side.

Note on the public-board analytics-event records. The analytics-event records that capture public-board page-views, entry-views, votes, comments, and broadcast open / click events store the visitor's IP and User-Agent in plaintext within the active retention window (target 90 calendar days; purge-provisioning gap disclosed in Privacy Policy § 11). Hashing of these fields at the storage layer is under consideration. This affects the server-side data record, not the visitor's terminal, and is therefore disclosed in the Privacy Policy rather than gated by this Cookie Policy.

#9. The future embeddable changelog widget

A common point of confusion: when (and if) a Workspace Operator, as a ProductLog customer, embeds a ProductLog changelog widget on its own website, the cookies / localStorage entries that widget sets are governed by the Workspace Operator's own Cookie Policy and its relationship with its visitors, not by this Cookie Policy.

ProductLog will act as the Workspace Operator's Processor for that flow under our DPA. At that point it will be the Workspace Operator's responsibility as Controller to:

• obtain any required visitor consent under § 25 TDDDG (or the local equivalent) before our widget loads on the Workspace Operator's site;
• disclose the embedded-widget activity in the Workspace Operator's own Cookie Policy;
• configure consent gating so the widget does not load before consent.

We will provide documentation on integrating consent gating; the implementation will be the Workspace Operator's. This Cookie Policy covers only cookies set on productlog.dev itself.

#10. Changes to this policy

We may update this Cookie Policy when we add new cookies, remove existing ones, change a third-party processor, or in response to legal developments. We will update the Last updated: date at the top of this document and bump the version. For material changes that affect the scope of consent already given (for example, adding a new Marketing cookie), we will re-prompt for fresh consent before activating the new cookie.

For an authoritative live view of the cookies we currently set, you may also inspect them via your browser's developer tools — the tables in § 4 are the documented inventory, but the live page is the ground truth.

#11. Contact

For questions about cookies on this Website:

JJ Online GmbH (operating ProductLog)

Schönhauser Allee 163, 10435 Berlin, Germany

Phone: +49 151 12032902

Email — general: [email protected]

Email — privacy and data-subject requests: [email protected]