Privacy Policy

1. Who controls your personal data, and how to reach us

The provider of the DiDiPick website and application (didipicks.com) is the controller of the personal data described here. In this document we are referred to as “we” or “us”, and you, the user of the service, as “you”.

The service is operated by an individual, not by a registered legal entity. If you need the controller’s legal name — to exercise your rights or to take legal action — request it at [email protected] and we will give it to you.

All personal-data matters go to [email protected]. This document gives no postal address, because we would rather give none than one nobody reads. If you or a regulator need a formal address, ask at that same address.

2. What this document covers, and how it relates to the Terms of Service

This document covers the personal data that arises from your use of DiDiPick: signing in, connecting a Facebook Page, saving clips and captions, scheduling posts, and publishing them.

This document explains what happens to your data; the Terms of Service at /en/terms explain who carries which responsibility. The two are read together, not one over the other. If their wording ever conflicts on a personal-data question, this document governs.

This document does not cover what happens on someone else’s platform once data leaves us — what Facebook, Google or Shopee do under their own policies. Section 8 states exactly what we send and to whom.

3. What we collect, and where it is kept

From signing in with Google: your e-mail address, your display name and your profile picture. Your e-mail address is the key that ties everything in the system to your account — every table in our database refers to you by it.

The access credentials for the accounts you connect yourself (a Facebook Page Access Token). Section 4 covers these separately because they are the most sensitive data in the system.

What you create in the app: the video links you paste, the clip files fetched, captions, product titles, affiliate links and the order you arranged your list in.

The posting schedules you set (what will be posted, to which account, at what date and time).

Publishing receipts: what was posted, to which account, when, whether it succeeded or failed, and the error text if it failed. We have to keep these because they are what counts your daily and monthly posting quota; delete them and the quota count is wrong.

Your plan and membership status.

If you buy a paid plan: the identifiers Stripe gives your customer record and your subscription, the date the period you paid for runs to, whether you have asked to cancel at the end of it, and the link to a bill that is still waiting to be paid. We also keep the identifier of every event Stripe sends us, so the same event can never be processed twice. We never receive your card number — see section 15.

A record of plan changes our staff make by hand: if we move you to a different plan ourselves (after you contact us, for example), we record who made the change, which plan it went from and to, when, and the reason that person typed. We keep this because changing a plan is a money decision, and without the record nobody can answer why your account is on the plan it is on.

The scheduler’s heartbeat (when the system last woke up to do its work). It holds nothing about you individually.

Some of this is also mirrored in your own browser (localStorage), separated by your e-mail address, so your screen comes back as you left it: the names you gave your accounts, your hashtag rules and your on/off switches — not the access credentials in section 4, which are not kept in your browser at all. That copy sits on your device and you can remove it yourself by clearing site data in your browser.

What you send through “Send feedback”: the title and details you type, your e-mail address, and any screenshots you choose to attach (up to 3), together with the context the form attaches by itself and tells you about on screen before you send — the app version, the language you are reading in, your plan, your browser and which screen you were on. We keep that set so we can reproduce the problem without having to ask you.

The screenshots you attach are stored in Supabase Storage in a bucket that is not public. Only our staff can open them, through a link that expires after 60 seconds, and the image is always re-encoded before it is shown — which is why data carried inside a photo file from a phone, such as where it was taken, does not reach the staff screen. The plain caveat: a screenshot is something you choose, so whatever is visible in it comes to us with it.

The internal note our staff write against a report, and the state that report is in (new / in progress / done / declined).

Server-side error messages are written to our hosting provider’s logs. Those messages may contain your e-mail address or the identifier of the record involved.

Our database is hosted by Supabase, not on a machine of our own. Sections 8 and 9 explain what follows from that.

A signal when the DiDiPick desktop app is installed or updated: the first time the app opens after an install or update, it tells us that an install or update happened, along with the app’s version number, the version it upgraded from, and the IP address the request came from. It can be sent before you sign in, and no e-mail address or anything else identifying you is attached. We use it to answer one question: how many installs happened and at which versions. We need this because we distribute the app ourselves, outside a store that would count it for us. If it cannot reach us, the app tries again the next time it opens, until it has been sent once for that version. The DiDiPick Connector extension does not send this signal, and sends nothing to our servers at all — it only talks to the DiDiPick app on your own computer.

Daily use of the DiDiPick desktop app: when you use the app with your account connected, we record that your e-mail address opened which app, on which day, and at which version. One row per day only — not one per click, and never what you did inside the app. We use it to answer two questions: how many people are genuinely using it, and which older versions are still in use, which is what tells us when we can stop supporting an old release without breaking anyone.

Installer downloads: when you press download for the DiDiPick app or DiDiPick Connector, we record your e-mail address, which one and which operating system, the version, and the IP address. We count these because both are distributed from our own site, not from a store that would count them for us.

4. The access credentials for your accounts (Facebook Page Access Token)

When you connect a Facebook Page to DiDiPick, you enter the access credential yourself: a Page Access Token.

Those values are held on our systems — on the Supabase database — and are encrypted with AES-256-GCM before they are written. We say this directly because it is true, and because Terms §9 already told you the same thing.

What that encryption does and does not cover, said plainly so you can judge your own risk: the key that decrypts them is held on the server that runs our app, which is not the machine the database runs on — the database is Supabase’s, as section 3 says. The key has to be there because the system has to decrypt them by itself to publish at a time you scheduled, while your browser is closed. So it protects you against someone who reaches the database or a backup file of it, because what they get is a value they cannot read without the key, and it does not protect you if our own server is taken over, because whoever takes that server can read both the key and the credentials that open the database.

These values are never sent back to your screen again, not even to you, and they are not kept in your browser. The settings page tells you only whether a value is stored, and its last four characters so you can tell which one it is. If you lose your own copy you will need a new one from Facebook — we are not your backup store for them.

We use them only to do what you asked: to publish and comment on your accounts, when you press publish or at the time you scheduled. We do not use them to read anything else in your account, and we do not pass them to anyone else.

You may withdraw this authorisation at any time, in two ways: remove the connected account in DiDiPick’s settings, or revoke access at Facebook itself, which makes the value we hold useless immediately. Once withdrawn, anything scheduled for that account will not run.

If you also want those values removed from our database, write to [email protected] — see section 12. Removing the connected account in settings stops the value being used in our system, which is what the app can do at once.

5. What we use it for

To sign you in and to know whose data is whose — without your e-mail address the system has no way to separate your data from anyone else’s.

To do the work you asked for: fetch a clip from the link you paste, write a caption, publish, and schedule publishing to the accounts you connected.

To count the posting quota your plan allows and to apply the platforms’ own limits, which requires your posting history.

To show you your history and results — what succeeded, what failed, and why.

To fix things when the system misbehaves, which means reading logs that contain an e-mail address or a record identifier.

To remember the language you chose, so you do not have to choose it again.

To take payment for a plan and open the entitlements you paid for, including issuing your invoice and receipt through Stripe and knowing when the period you paid for ends.

We do not use your data for advertising, we do not analyse your behaviour, and we do not sell your data. Section 15 lists what this system does not have at all.

6. The legal bases we rely on

Performance of a contract: your sign-in data, account credentials, clips, captions, schedules, publishing receipts and — if you buy a paid plan — the payment data in section 3 are what the service you asked for needs in order to work. Without them we cannot provide it.

Your consent: entering the access credential for a Facebook Page is your consent for us to use them to publish on your behalf. You may withdraw that consent at any time under section 4. Withdrawing it does not make our earlier use unlawful.

Our legitimate interests: keeping error logs, and keeping publishing receipts in order to count quota and prevent use beyond a plan, are necessary to keep the service working and fair to every user.

Legal obligation: where the law or a lawful order requires us to keep or disclose data, we comply to the extent required.

7. The cookies we set (there are two, and that is all)

A session cookie named didipick_session_v1 — it remembers that you are signed in. It is HttpOnly (page JavaScript cannot read it) and SameSite=Lax, and it lasts 30 days. It is necessary for the service: block it and you cannot sign in.

A language cookie named didipick_lang — it remembers the language you chose, for 365 days (one year), so the system does not re-guess it from your browser on every visit.

We set no advertising cookies, no cross-site tracking cookies, and no third-party cookies of any kind.

8. Who we send your data to

Google — to verify who you are when you sign in. Google is what tells us the e-mail address is really yours.

Meta (the Facebook Graph API) — when you publish a Reel or a comment, we send the clip, the text and your Page’s credentials to Meta in order to do it.

Shopee — when you paste a product or video link, the system calls shopee.co.th to fetch the clip file and the product title behind that link. That call happens because of the link you pasted.

Supabase — the database provider that holds every table named in section 3, including the account credentials in section 4.

Stripe — our payment processor. When you buy a paid plan we send Stripe your e-mail address so it can create your customer record, bill you and send you the receipt. Your card details go from your browser to Stripe directly and never pass through our servers. PromptPay payments are collected through Stripe’s Thai entity, which is the name that appears in your bank app.

Our web hosting provider — whoever runs the servers that serve our pages and API, and who holds our error logs.

We do not sell your personal data, and we do not trade it with anyone for marketing purposes.

Beyond the list above, we disclose your data to others only where the law or a lawful order requires it.

9. Transfers out of your country

The recipients in section 8 are international providers, so your data is processed on servers that may sit outside Thailand, which may include the United States and other countries.

We transfer data abroad only as far as providing the service you asked for requires, and under the data-protection terms those providers apply to their own customers.

If you do not want your data processed outside Thailand, you cannot use this service: the whole of its infrastructure sits with those providers.

10. How long we keep it

The plain fact first: nothing in our system deletes your data automatically. There is no routine anywhere that removes a user’s data when they stop using the service or when any period elapses. The data in sections 3 and 4 stays in our database until a person removes it.

So deletion happens when you ask: write to [email protected] and we will delete it within 30 days — see section 12.

One consequence we will state rather than hide: the publishing receipts are what count your quota. If you ask for all of them to be deleted, your past quota count goes with them.

A report you send through “Send feedback” stays until a member of our staff removes it, which is somebody pressing delete rather than any schedule. When they do, the screenshots attached to it are deleted in the same action — no copy is left behind in storage.

What we hold about your payments — the identifiers in section 3 — stays with your account until you ask us to delete it, like everything else here. Stripe keeps its own record of each payment, invoice and receipt for as long as its terms and the law require; that copy is not ours to delete, and you can ask Stripe about it directly.

Cookies expire on the schedule in section 7. What sits in your browser’s localStorage stays until you clear site data yourself. Our hosting provider’s logs are kept for whatever period that provider sets, which is not ours to decide.

11. How we protect your data, and what we do not guarantee

What we actually do: traffic between your browser and our servers uses HTTPS · the session cookie is HttpOnly and signed with a secret that exists only on the server, so a browser cannot forge one · every API request works out who is calling from that cookie and never from a value the browser supplies, so no request can read another account’s data by changing an e-mail address · our database is Supabase’s, and the credentials that can read it exist only on our server, never in your browser · the access credentials in section 4 are encrypted before they are stored and are never sent back to the browser, within the limits section 4 sets out.

What we do not guarantee: no system is perfectly secure. We do not guarantee that unauthorised access will never happen. Terms §9 and §15 already set out the limits of our liability on this.

If your personal data is exposed or accessed without authorisation, we will notify you and the relevant authorities without undue delay, as far as we are able.

What you can do to reduce your own exposure: use a Page Access Token with no more permission than it needs, and revoke access at Facebook when you stop using the service — see section 4.

12. Your rights, and how to exercise them

You have the right to ask for access to and a copy of the personal data we hold about you · to have inaccurate data corrected · to have data deleted · to have its use suspended · to object to certain uses · to withdraw a consent you gave · and to have your data given to you in a machine-readable form.

There is one way to exercise them: write to [email protected] from the same e-mail address you sign in with, so we know it is you. If you write from another address we will ask you to verify your identity first, because sending your data to someone who is not you is the one mistake that cannot be undone.

We will answer and act within 30 days of receiving your request. If a request is complex enough to need longer, we will tell you why before that period ends.

What you should know before asking for deletion: the data in sections 3 and 4 is what makes the service work. Once it is deleted, your schedules will not run, your saved clips and captions are gone, and you will have to connect every account again if you come back. We cannot restore it.

Exercising your rights is free, and doing so will never cause us to treat you worse.

13. Children and young people

This service is not intended for anyone under 18. Terms §3 requires users to be at least 18 years old, and this document uses the same threshold so that our two documents cannot contradict each other.

We do not knowingly collect data from anyone under 18, and we have no age verification: the only thing we know about you is what Google sends us at sign-in, and an age is not part of it.

If you are a parent or guardian and find that a minor in your care is using this service, write to [email protected] and we will delete the account and the data attached to it.

14. For users in the EU, the UK or the EEA

If you are in the European Union, the United Kingdom or the European Economic Area, this section applies to you in addition to everything above, and the GDPR (or UK GDPR) applies to your data.

The legal bases we rely on for you are the same set as in section 6: performance of a contract (GDPR Art. 6(1)(b)), consent (Art. 6(1)(a)), legitimate interests (Art. 6(1)(f)) and legal obligation (Art. 6(1)(c)).

The rights in section 12 cover the full set in GDPR Arts. 15 to 22, including data portability and the right to object to processing that relies on legitimate interests.

You have the right to complain to the data-protection authority in the country where you live if you believe we handle your data wrongly. You may do that without contacting us first.

Two things we state plainly that we do not yet have, so that you are not misled: we have not appointed a representative in the European Union under GDPR Art. 27, and we do not have an internal process that can guarantee breach notification within 72 hours under GDPR Art. 33. What we can commit to is notification without undue delay, per section 11. Every data matter goes to [email protected].

Your data is transferred outside the EEA as described in section 9. That follows from the providers we use; it is not an extra option we opened.

15. What this system does not have at all

No behavioural analytics, no Google Analytics, no usage-tracking tool of any kind on our pages.

No advertising, no ad network, and no user profiling for marketing.

No sending of your data to a third-party artificial-intelligence provider to read or learn from.

No card number and no bank details anywhere in our system. Payments are taken by Stripe, and what stays on our side is the identifiers in section 3 and whether your plan is paid up.

No sale or rental of your personal data.

16. Changes to this policy

We may revise this document when the system changes, because its job is to say what the system actually does. A document that lags behind the system is a document that misinforms.

Every revision changes the version number and the effective date printed at the top of this page, so you can always tell which version you are reading.

If a revision materially affects your rights — a new recipient of your data, or a new purpose for using it — we will tell you before it takes effect, in the app or by e-mail to the address you sign in with.

The version that applies to your data is the one published at /en/privacy at the time.

17. Contact us

For anything about personal data — exercising a right under section 12, requesting the controller’s legal name under section 1, requesting a formal address, or complaining about how we handle your data — write to [email protected].

If you are in Thailand and are not satisfied with our answer, you may complain to the Office of the Personal Data Protection Committee. If you are in the EU or the UK, see section 14.