Privacy notice
This site measures its own traffic. There is no Google Analytics, no advertising network, no embedded maps and no third-party scripts, and no element of the page is fetched from any server other than this one: not a typeface, not a video player, not a social button. The code that performs the measurement is part of the site, and the data it produces is kept in a database hosted on the same server that serves the page. Only two categories of data leave this server, in both cases on the user’s own initiative: the content of an appointment request sent through the form, transmitted by email to the studio, and the newsletter’s messages, delivered to the address of whoever asked to receive them.
Data controller
The data controller is Sevenink Tattoo Studio, Via C. Nitti 129/A, Taranto, VAT 03433930736. The studio is run by a single individual: there is no organisation behind it and no data protection officer has been appointed, neither being required at this scale.
Requests concerning anything described in this notice may be addressed to daniele@seveninktattoo.it, or sent to the studio’s contact details given at the foot of the page.
Data collected and purposes
Collection takes place solely with the data subject’s prior consent, and only after it has been given. None of the items listed below is measured before the banner has been answered, and declining keeps it that way: the measurement code is not even downloaded. Declining carries no consequence — the site behaves identically either way.
- The pages opened and the address of each, the one the visit started on, and the time spent on each
- To know which pages are read and which are not.
- Sections reached and the time each spends on screen
- To decide whether the page is worth scrolling to the end.
- Scroll depth reached — 25%, 50%, 75%, 100%
- The same check, in a more direct form.
- Which works are enlarged, and how long the image stays open
- To understand which subjects and which styles genuinely interest visitors.
- Whether the booking form was seen, whether filling it in was begun, which options were chosen and whether it was sent
- To find where the form loses users. The options are recorded as labels — realism, forearm — and never together with what was typed into the free-text fields.
- Whether the navigation menu was opened and which section was jumped to, and whether a link to Instagram, WhatsApp or maps was followed
- To learn how people move around the site and which contact method they prefer.
- Device type, operating system and browser, recorded as three short labels such as mobile, ios, safari. The full identifying string sent by the browser is read, reduced to those labels and discarded.
- To know the environments the site must render correctly in.
- Screen and window size, language, time zone
- The same check, in more detail.
- The name of the referring site — the host only, so instagram.com and not the post — together with any campaign parameters in the link. The full address offered by the browser is read in order to extract the host and then discarded.
- To learn where visits come from.
- A two-letter country code, and only where the network in front of the site has already determined it and declares it. No lookup is performed and no database exists for the purpose, so the field is frequently empty.
- To learn which countries the site is read in. No city, no coordinates, no more granular data.
The booking form
Consent does not apply here. The user gives a name, a means of contact — email or phone, their choice — and a description of the project; they also choose a style, one or more parts of the body and a rough size, and may state the time frame within which they would like it done. Each of these four items is chosen from a closed list of options offered by the site, and is not a free-text field. The first three have to be answered — a request that says neither the style, nor where, nor how big cannot be quoted for — and each of them includes an option for somebody who has not yet decided: “let’s decide together”, “other”, “I don’t know”. The fourth is optional. The only consequence of not providing them is that the request cannot be sent from this form: the telephone and the other contact details at the foot of the page remain. Sending the form is itself the appointment request, and refusing to read it would mean ignoring the user, not protecting them. There is no other field, hidden or otherwise, save for a decoy field filled in only by automated agents.
Before sending, a box has to be ticked declaring that this notice has been read. That is an acknowledgement and not consent: the processing described in this section rests on Art. 6(1)(b) GDPR, and a box asking you to «agree» to something that happens anyway would be consent in appearance only. The box is not pre-ticked, the form does not send until it is ticked, and the tick is not recorded anywhere: what remains is that without it the request cannot be sent.
The part of the body is an indication of where the design goes and not a health datum, and the answer being required does not change that: it is chosen from seven offered placements, the last of which is “other”, and none of them says anything about the health of the person writing. The form does not ask for, and must not contain, information about medical conditions, pregnancy, allergies or ongoing treatment. Whatever needs to be known in that regard is asked in person, before the session, on the paper informed-consent form required for the procedure — a document that follows its own rules and does not pass through this site.
The content of the request is transmitted by email to the studio and is also recorded — name, contact, project description, the chosen style, area or areas and size, and the timing where given — in a table of the same database that hosts this site’s statistics, on the same server that serves the page. The record answers the request itself and rests on Art. 6(1)(b) GDPR — pre-contractual measures taken at the data subject’s request — and not on consent: sending the form does not amount to agreeing to any further processing. The row is readable only by the panel’s accounts, password-protected, and is deleted automatically after 365 days by the same nightly routine that applies the statistics’ retention. The email delivered at the moment of sending is a separate copy, which remains in the controller’s mailbox for its own lifetime: neither the automatic deletion nor the tools on this page reach it. Before the 365 days expire you may request early deletion or rectification of the request by writing to the address given at the top of this notice. The contact given in the form is also used to keep a fifteen-minute waiting interval, so that a double submission is not sent twice — the same kind of file used by the per-IP limiter described below, named by a hash of the contact and not by the contact itself.
The newsletter
Subscribing to the newsletter is optional and rests on the data subject’s consent — Art. 6(1)(a) GDPR — given through the dedicated checkbox, not pre-selected, in the form. The only datum requested is the email address: neither a name nor any other information of any kind is asked for.
The process uses double opt-in. A single message containing a link is sent to the address given; until that link is used the address stays in a pending state, receives no other message and is deleted automatically after seven days. It follows that entering someone else’s address produces no effect beyond a single message to the rightful owner of the mailbox. The date of confirmation is recorded, and it is what lets the controller prove the consent received.
Every message sent to subscribers contains a link for immediate unsubscription, usable without giving reasons and without signing in to anything; the same messages also carry the List-Unsubscribe headers, so the unsubscribe function offered by the mail program works just as well. On unsubscription the row is not deleted but marked as cancelled, together with the relevant date: this is what lets the controller prove when they stopped writing. Full deletion of the row may be requested by writing to the address given at the top.
The address is kept as long as the subscription lasts: unlike the other data described on this page it has no automatic expiry, since an expiry would mean ceasing to write to someone who asked to receive. The messages are sent from the same server that serves this page, using the studio’s mail account; no third-party platform is used. There are no tracking pixels, message opens are not detected and followed links are not recorded: the controller knows that a message was delivered and nothing more.
Data not collected
IP addresses are never written to the database. No table that records a visit has a column meant to hold them. They are used for one purpose only: rate-limiting requests, so that a single machine cannot flood the booking form or the counter. Even there the address is not recorded: it is hashed, and the hash is the name of a small file containing a number. The count they hold expires within minutes or hours depending on the limit, and the file is removed by a periodic sweep once more than twenty-four hours have passed since the last access.
For accuracy, since it is a claim that deserves checking: the web server in front of the application keeps its own access log, as every web server on the network does, and a line of that log contains an address. That is infrastructure, not measurement: it is never linked to anything described in this notice, and in this database there is a single row containing an IP address — the one for the controller’s own logins, described below.
There is no profiling, no automated decision-making, no cross-site tracking and no attempt to identify the user. The identifier held in pf_vid is a random number with no meaning outside this site. No name, contact or account is attached to it, there being no visitor accounts to attach it to. The photographs of the works published on this page show areas of tattooed skin and not faces, and are published with the consent of the people portrayed.
Cookies
| Name | Function | Retention | Consent required |
|---|---|---|---|
pf_consent |
Records the answer given to the banner — yes or no, and the numbered request it refers to — so the question is not asked again until that request changes. It is written by the page itself and is the only cookie present before an answer has been given. | 6 months | No. It exists to record a choice, including a refusal. |
pf_vid |
A random number that tells one browser from another, so a return visit is not counted as a second person. It is written by the server and only after consent has been given. | 13 months, renewed on every visit | Yes |
pf_sid |
Groups the events of a single visit. A new one starts after 30 minutes of inactivity. | 30 minutes | Yes |
pf_admin |
Authenticates whoever runs the admin panel. It is issued only against a correct password and, where the account has two-step verification switched on, its code; it therefore never reaches a visitor’s browser. | The browser session; the matching session on the server expires after 7 days | No. Technical, and not relatable to the visitor. |
All four are first-party: set on this domain, returned only to this domain and unreadable by anyone else. There are no others — no advertising cookie, no pixel, no embedded video player, no social button and no embedded map — and no visit information is kept in their place in the browser’s local storage: the only value written outside the cookies is a flag remembering whether the opening animation has already been shown, and it goes when the tab is closed.
Data that leaves this server
The content of an appointment request, if one is sent, and the newsletter’s messages, to whoever subscribed to it. Both leave by SMTP: the request reaches the studio’s mailbox, the newsletter message the subscriber’s. The provider that carries them and the one that hosts those mailboxes handle them as the postal service handles a letter: they are on the path because mail cannot be sent without them. The same path carries the service messages sent to whoever runs the site, described below. The list ends there.
Loading a page involves contact with no other party. Every file the page needs — stylesheets, scripts, photographs and the three typefaces used — is served from this domain, so the browser never announces itself to a server not run by the controller. The links to Instagram, WhatsApp and maps are links and nothing more: none of the three loads anything on this page, and none of the three knows about the visit until it is deliberately followed. There is no analytics provider, no advertising partner, no external booking system and no list the contact is added to. The company that hosts the server has access to its own disks, as with any hosted site.
No data is deliberately transferred outside the European Economic Area. The email path is the one point where that could happen, and it depends on the provider carrying the message.
Legal basis and retention
Analytics — the data subject’s consent, Art. 6(1)(a) GDPR, together with Art. 122 of the Privacy Code as regards the cookies themselves. Consent may be withdrawn at any time, below, and withdrawal is exactly as easy as giving it. Two distinct periods apply, worth keeping separate: the identifier kept in the browser, pf_vid, lasts 13 months — the limit set by the Garante for an analytics identifier — and is renewed on every return; the rows kept on the server are deleted after 400 days, by a nightly routine.
The booking form — Art. 6(1)(b): pre-contractual measures taken at the data subject’s request. The request is kept on the server, as well as in the studio’s mailbox, for 365 days, then deleted automatically by the same nightly routine described above; the basis remains the request itself, not consent.
Protection against overload — Art. 6(1)(f), the controller’s legitimate interest in the site’s availability. Counters only, expiring within minutes or hours, their files removed by the day after the last access.
The consent cookie and the login cookie require no consent: Art. 122 of the Privacy Code exempts the cookie strictly necessary to provide the service requested, and recording a refusal falls precisely within that case.
The panel’s accounts
Statistical data and the appointment requests are viewed on a panel behind a login, and that login corresponds to an account: a name, an email address, a password kept only as a hash, and, where switched on, two-step verification — the secret used by an authenticator app, together with a set of recovery codes, likewise kept as hashes. Two-step verification is optional; where it is on, the password alone is not enough to sign in, and a code already used is recorded as such and cannot be presented a second time.
The login is recorded — the moment, the originating address and the browser used — so the session can later be recognised and revoked. Those rows are removed when the session expires, within seven days of its last use.
Whoever has forgotten the password may ask for a reset link to be sent to their own address: only the cryptographic fingerprint of that link is kept, for thirty minutes, and it is deleted on first use. Changes touching an account’s security — password changed or reset, two-step verification switched on or off, recovery codes regenerated — are announced to that account’s own mailbox, so that unauthorised access cannot happen quietly.
None of the above is data relatable to the visitor: it concerns the controller and whoever runs the site on their behalf. It is stated here for one reason: a page that declares that visitors’ addresses are never kept must account for the one point in this database where an address is kept.
Rights of the data subject
Under Articles 15 to 22 GDPR the data subject may request access to the data concerning them, its rectification or erasure, restriction of processing or a copy in a portable format, and may object to processing. Under Art. 7(3) consent may be withdrawn at any time, without affecting the lawfulness of processing carried out beforehand. Under Art. 77 a complaint may be lodged with the Garante per la protezione dei dati personali — garanteprivacy.it — without first approaching the controller.
The quickest route, in practice, is the command given below. The “cookies” link in the footer leads there too: on the main page it reopens the banner in place, while on this page and in the admin panel it leads straight to this block. Declining, by either route, immediately deletes the identifiers from the browser, after which nothing further can be linked to the visitor.
The rows already written remain and contain no name, no contact and nothing traceable to a person. Under Art. 11 GDPR a controller who has no reason to keep the additional information needed to identify a person within an anonymous set is not obliged to acquire it for the sole purpose of answering a request — which is the case here, and is also why those rows cannot be singled out unprompted. Should their deletion likewise be requested, the value of the pf_vid cookie must be given to the controller before it is removed: it is the only key that exists and allows manual deletion.
Revisions
Rewriting this notice does not reopen the answer already given. Consent is given in relation to what is collected and to its purposes, not to a document: correcting a sentence, or explaining something more clearly, leaves an assent or a refusal already expressed valid exactly as before. What does reopen the question is a change to the request itself: a new cookie that needs permission, a third party appearing on the page, a new purpose, a new category of data counted.
The request is therefore numbered, and the number that was answered is kept in the pf_consent cookie together with the answer itself. When it changes, every stored answer ceases to have effect and the banner is shown again — which is why it changes only in the cases above. The list below indicates, for each revision, which kind it was.
- 11 August 2026 · request 01 First publication of the Sevenink Tattoo Studio site, together with the counting it describes.
- 13 August 2026 · request 01 Rewrite of the banner and the cookie table for greater clarity, and the addition to the banner of a panel listing the three cookies set and their lifetimes. No change to what is collected or to the purposes.
- 13 August 2026 · request 01 Requests sent by the booking form are now recorded — as well as transmitted by email as before — in a table of this site’s database, readable only by the controller’s account, so they can be reread from the admin panel; they are deleted automatically after 365 days. The booking form, the legal basis applied and the form’s introductory note have been updated accordingly. The basis remains the request itself and not consent, so the banner request does not change.
- 14 August 2026 · request 01 The site now offers a newsletter, with optional double opt-in subscription: the email address is kept as long as the subscription lasts, and every message contains the link to cancel it. The section “The newsletter” has been added. In the same change the booking form was moved to a page of its own: what is collected and the purposes have not changed.
- 14 August 2026 · request 01 The booking form offers a fourth choice, the time frame within which one would like the tattoo done, also from a closed list of options. It is kept together with the rest of the request and for the same duration.
- 20 August 2026 · request 01 The booking form now requires a style, an area and a size — each with an option for somebody who has not yet decided — and the area accepts more than one answer; the time frame stays optional and is now actually transmitted and kept. Before sending, a box confirms that this notice has been read: an acknowledgement, not consent, and it is not recorded. In the same revision: the newsletter was added to the list of data that leaves the server, the list of what is measured now also names the pages opened and the use of the menu, the lifetime of the login cookie and of the rate-limiter files were corrected, and the password reset for the panel’s accounts is described. None of this changes what is collected about visitors or the purposes.