Privacy Policy
What this document is about
Segmentic is a platform a company uses to measure how its own users behave and to send messages to those same users. So there are two groups of people in this document, and they are not treated the same way: the customer's staff, who log in to the dashboard, and the customer's end users, who never see the dashboard.
This document says what data is collected, for what purpose, where it is kept and for how long, and who decides each of those things.
The order of the articles follows the "Executive Instruction on Improving the Protection of User Privacy and on the Manner of Collecting, Processing and Storing User Information in Cyberspace Systems and Platforms", approved at session 127 of the Supreme Commission for Regulating Cyberspace in the Iranian year 1402 (early 2024). The reason is plain: if a regulator ever measures this document against something, that is what it will measure it against.
Article 1Two layers of data, and who decides for each
This is the most important article in the document, because every other article takes its meaning from it.
**Layer one, the customer's own account.** The name and email address of the person who signs in to the dashboard, and the record of what that person did there. Here Segmentic is the data controller, meaning we decide the purpose and the means of the processing.
**Layer two, the customer's end users.** The events, profiles and contact channels the customer sends us. Here the customer is the data controller and Segmentic is the data processor. Which data comes in, which segment is built, which message goes out and what is deleted is decided by the customer, and we act on the customer's written instruction and no further.
Note 1 of the 1402 instruction places liability for a privacy breach on the "service provider", but in a two layer chain it does not say who the service provider is. Iranian law still has no controller and processor distinction, so the statute does not resolve that ambiguity and a contract has to: as regards end users, the service provider is the customer.
تبصره 1: The two terms "data controller" and "data processor" are contractual in this document. Current Iranian law does not draw that distinction. We have adopted it now so that if a personal data protection act is passed, this document stands without being rewritten.
Article 2End user data: where it comes from and what is collected
We do not take end user data from the end user. The customer sends it to us from the customer's own app or website, through our SDK or through the API. Collection is therefore indirect, and the relationship that matters is between the end user and the customer, not between the end user and us.
Read the last column this way. Required means the service does not work at all without it. Optional means sending it is the customer's decision, and not sending it only closes off certain features.
| Data item | Purpose | Required or optional |
|---|---|---|
| User identifier `user_id` | Tying events to one person and enforcing frequency caps | Required |
| Anonymous identifier and session identifier | Following behaviour before the user signs in | Required |
| Event name, event time and event properties | Behavioural analysis, building segments, triggering journeys | Required |
| Event IP address | Detecting city and region, detecting bot traffic, investigating abuse | Required |
| Browser, operating system, device type and model | Reporting and choosing the right channel | Required, in derived form |
| Mobile number | Sending SMS | Optional |
| Email address | Sending email | Optional |
| App push token and browser push subscription endpoint | Sending notifications | Optional |
| Messenger conversation identifier | Sending messages over a messenger | Optional |
| First name, last name, gender, date of birth, national id | Personalising message text | Optional |
| The customer's own custom attributes | Segmenting on the customer's own business data | Optional |
| Purchase amount and order count | Measuring campaign impact | Optional |
| Send, delivery and unsubscribe records | Proving a message was sent and enforcing an unsubscribe | Required |
تبصره 2: The raw User-Agent is not stored on events. Only the three columns derived from it, browser, operating system and device, are kept. There is one exception: the raw User-Agent stays on a browser push subscription, because without it there is no way to tell which browser a dead subscription belonged to.
تبصره 3: Our web SDK sets no cookies at all. The anonymous identifier is held in `localStorage`, together with one entry in `Cache Storage`. The only cookies in the system are the dashboard session cookie and the dashboard language cookie. The detail is in the cookie and browser storage policy.
Article 3Customer account data
There is no self-serve signup and an account is created only by invitation. So the data in this layer comes from the person themselves, while they accept the invitation, and from no other source.
| Data item | Purpose | Required or optional |
|---|---|---|
| First and last name | Display in the dashboard and in the record of actions | Required |
| Work email address | Sign in, password recovery, formal notice | Required |
| Phone number | Two step verification and support contact | Optional |
| Sign in and action history in the dashboard, including IP address and User-Agent | Account security, and answering who did what | Required |
| In-panel notifications and when they were read | Showing what happened in the account, and who was told | Required |
| The fact that you signed in, with which account you signed in to and your role in it | Sending the getting-started guidance and the reminder to connect the SDK | Optional, and can be switched off |
| How the account looks to us: whether the SDK is connected, how many days of the trial remain, and how much of the allowance is used | Telling you the trial is ending, and suggesting a plan that fits better | Optional, and can be switched off |
An in-panel notification holds no end user data. Its row carries a campaign name, a ticket subject or a percentage of an allowance, which is the handful of values the sentence on the screen needs, and never a contact's phone number or email address.
This data is not sold to anyone and is not given to any third party.
The last two rows of the table above stand apart from the rest and deserve to be stated plainly. They are used to send messages about this service itself: the getting-started guidance, the reminder to connect the SDK, the notice that a trial is ending, and a suggestion of a plan that fits better. Those messages are sent with the same product we sell to customers, from an account on this same installation that belongs to us, and none of that data leaves the installation. It is used for no other advertising purpose, and for no other product or company.
You can switch that one item off whenever you like, by writing to privacy@segmentic.net. After that your sign-ins are no longer recorded for this purpose and you receive no messages of this kind. The other rows stay as they are, because the account does not work without them: there is no signing in without an email address, and an action history without an IP address answers no security question at all.
--- Note: switching this off is switching off the messages. If you also want the data already collected from those two rows to be deleted, that is an erasure request and goes through the article on deleting data.
Article 4Demo requests from the marketing site
The two groups above, the customer's staff and the customer's end users, both exist once a relationship has started. There is a third and smaller group that comes before it: somebody who fills in the demo request form on the marketing site and has no account of any kind. Segmentic is the data controller here too, because the person gave us the data directly and we set the purpose.
| Data item | Purpose | Required or optional |
|---|---|---|
| Name | Addressing the person on the call | Required |
| Organisation name | Knowing what the call is about | Required |
| Email address and phone number | The call itself | Required |
| Company website | Looking at the business before calling | Optional |
| Description of the problem | Arriving at the call prepared | Optional |
| The language of the page the form was filled in on | Answering in that language | Required |
| Referring page and campaign parameters in the address | Knowing where the request came from | Required |
| Browser user agent | Recognising a flood of automated requests | Required |
| Follow-up state and the note left by whoever called | Stopping two people calling the same person | Required |
No IP address is stored. The only thing it could have been kept for is telling a machine apart from a person, and the form's bot trap and the rate limit on that route already do that.
This data is used only to make contact about that request. No marketing list is built from it, it is not sold, and it is given to no third party.
--- Note: the form carries a hidden field that only bots fill in. Its value is never stored, and a non-empty one only causes the request to be discarded.
These rows are not covered by the retention setting, because that setting is for end user data and there is no account here yet. They stay until somebody deletes them. Write to privacy@segmentic.net at any time and your row is deleted, whether anybody has called you or not.
Article 5Limited purpose and minimal data
Clause 1-2 of the 1402 instruction and paragraph (b) of article 59 of the Electronic Commerce Act 1382 say the same thing: collect only as much as is necessary and proportionate to the purpose that was declared, and use it only for that purpose. Two undertakings follow from that rule:
- The end user data of a customer is not reused for our own purposes. No shared model is built on it, it is not handed to another customer, and it is not analysed in a pool across customers.
- The content of customer data is not inspected beyond what providing the service and fixing faults requires. Article 2 of the Computer Crimes Act 1388 makes unlawful interception of data in transit a criminal offence, so this undertaking rests on more than goodwill.
Article 6Data that must never enter the system
Article 58 of the Electronic Commerce Act 1382 makes it unlawful, without the explicit consent of the person, to store, process or distribute personal data revealing ethnic or racial origin, ideological view, religion, moral characteristics, or physical, mental or sexual condition. Article 71 of the same act makes a breach of it a criminal offence carrying one to three years imprisonment, not a fine.
So these attributes enter the system neither as a profile attribute nor as a segment condition. Medical and health data is prohibited separately and absolutely. Article 60 handed that category to a regulation of its own, and it is not clear that any standard usable by the private sector ever came out of it. While that remains unresolved, the prohibition is total.
تبصره 4: If a customer uploads such data under an unrelated name, the system cannot detect it and responsibility rests entirely with the customer.
Article 7Encryption and security
Clause 1-4 of the 1402 instruction says that personal data relating to identity "must be stored in encrypted form only". That is not a best practice, it is a requirement, and we write it as an undertaking rather than as a description of how things happen to stand today.
Identity data is encrypted at rest, data in transit moves over TLS, staff access is granted on a least privilege basis and is logged, and the credentials for sending channels are kept apart from the data. The technical detail is in the security document.
Article 8Where data is stored
Data is kept on infrastructure inside Iran.
No general binding law today compels an Iranian private company to do that, and the two documents that would change it have not been passed. So this is our own choice and not compliance with a duty. If the storage location ever changes, notice is given before the change takes effect.
Article 9Sub-processors
Delivering a message is not possible without other services: Iranian SMS gateways and the notification services of the app stores. Delivering a notification means that the device token and the message text reach that service, and some of those services sit outside Iran. We write this plainly, because leaving it out would turn the sentence "data is kept on infrastructure inside Iran" into a false claim.
A current list of sub-processors, with name, service and place of processing, is published, and a new one is announced before it is put to use.
Article 10Retention and deletion
The retention period is configured for each customer separately, and the control for it is in the dashboard.
Clause 1-3 of the 1402 instruction wants deletion at a user's request to be carried out "immediately", wants data to go to an offline backup only where the law requires it, and wants it "completely destroyed" once the legal retention period has run out. That is what the system does, with two exceptions:
- Logs and traffic data are kept for at least the minimum period set by the laws in force, even where a deletion request has been carried out.
- The unsubscribe list is not wiped. If it were wiped, the same number or address would start receiving messages again, and that is precisely a breach of what the person asked for. Only the address itself and the reason for the unsubscribe stay on that list.
The figures and the implementation detail are in the data retention and deletion policy, and are deliberately written in that one document only.
Article 11Right of access, correction and erasure
Article 59 of the Electronic Commerce Act 1382 says, at paragraph (d), that a person must be able to reach their own computer records and to correct data that is incomplete or wrong, and at paragraph (e) that they must be able to ask for their own file to be destroyed. Neither of those is settled by a sentence in a policy. They have to be features of the product. They are.
For an end user the correct route is the customer, because the relationship is with the customer and so is the data. A request that reaches us directly is referred to the customer, and we do not touch the customer's data without the customer's instruction, unless the law rules otherwise.
Unsubscribing from messages is a separate route: the preference and unsubscribe centre is available to the end user directly and needs no written request.
Article 12Security breach
If a security breach affecting customer data is confirmed, the customer is notified within 72 hours of the confirmation, with whatever is known by then: what happened, how far it reached, what has been done about it.
This is a contractual undertaking, not the discharge of a legal duty. Iran today has no legal data breach notification duty at all, neither towards individuals nor towards a supervisory authority, because no data supervisory authority exists. The number is one we set ourselves, and we present it as exactly that.
Notifying end users, where that becomes necessary, is for the customer to do, because the relationship is theirs.
Article 13Changes to this document
A change to this document is announced at least 60 days before it takes effect. That number comes from the note under clause 1-1-3 of the 1402 instruction, which requires at least two months, and not from the thirty day templates in common use.
If a change is substantive, meaning that it alters the purpose of the processing, the data items or the retention period, consent is taken again. For this document, continued use on its own does not count as acceptance.
About this English text
This document is governed by Iranian law and the Persian version is the authoritative one. Where the two texts differ in any way, the Persian text prevails and the English text has no independent meaning. Dates of Iranian legislation are given in the Iranian solar calendar, which is how they are cited in Iran.
Contact
Privacy requests and questions: privacy@segmentic.net
Support: support@segmentic.net
Kargostaran Nasl Javan Bakhtar https://segmentic.net