Privacy

Privacy policy

Last updated: 23 September 2026.

Decor Map is an unofficial, community-run companion for the mobile game Pikmin Bloom. It is not affiliated with, endorsed by, or operated by Nintendo or the publishers or operators of Pikmin Bloom. This policy covers the Decor Map website and the mobile app Decor Finder: Bloom Locations (皮皮飾品地圖 in Traditional Chinese). It describes what the service actually does today. Where a capability is built but not switched on, it says so rather than describing an intention as a practice.

What we collect from you

• Account data: an email address and a hashed password if you create an account (guest sessions store neither). Password hashing happens in the database (bcrypt via pgcrypto); the application never stores plaintext passwords.
• Contributions: the observations you submit — location coordinates you chose to report, category, result, optional note, and timestamps. Contributions are attributed to your handle only if you enable a public profile; otherwise they appear as “contributor”.
• Collection and saves: which decor variants you mark and which locations you save, so the product can work.

What we never collect

• No game account credentials or in-game data — connecting them is prohibited.
• No background location tracking. Your device location is used only while you are using the app, when you grant it, to center the map or prefill a report. The app does not ask for background location permission.
• No facial recognition, and no inference of sensitive personal attributes.

Your location

Location permission is used while the app is open, to center the map on you and to prefill a report. Two things send a position beyond your device:

• A report you submit. The coordinates you chose for that place are stored as part of the observation, because the map is made of them.
• The Pro hunt planner. When you ask it for a route, your device’s current position is sent to our server so it can order nearby places. The reply to that request contains the position you sent, and that reply is written to a short-lived cache that exists so a repeated request cannot be carried out twice. A cached reply stops being used 24 hours after it is written. Expired entries are no longer served, but they remain stored until they are deleted; there is no automated job that purges them today.

Your GPS position is not sent to the advertising SDK described below.

Advertising in the mobile app

The mobile app shows advertising to people who are not subscribers. This website shows none. Advertising is provided by the Google Mobile Ads SDK, and what that SDK collects goes to Google:

• your device’s advertising identifier, and other device identifiers where applicable;
• your IP address;
• app interactions, such as which advertisement was shown or tapped;
• diagnostic information, such as crash and performance data.

Google may use your IP address to estimate your general location. We do not send your GPS position to the advertising SDK.

We do not ask your age, and we do not guess it. The app collects no date of birth and no age bracket, and it infers nothing about your age from your payment method, your email address, a device setting or the fact that you play a game. Because we have no age signal, we do not tell Google that you are a child and we do not tell Google that you are an adult; we set a content rating ceiling on the advertisements themselves instead, so nothing above a 13+ rating is requested.

The SDK is not started until consent permits advertising requests, where consent is required. Until then it is not initialised at all, rather than started and held back — because initialising an advertising SDK can itself begin collecting identifiers. Where your jurisdiction requires the choice to remain available, you can reopen it at any time from Settings in the app.

Advertisements are requested as non-personalised. You do not need an account to use the free app, and you do not need one to be shown an advertisement either — a subscription is what removes advertising.

Subscriptions and purchases

Subscriptions are processed by RevenueCat, working with the app store you bought from. RevenueCat receives your purchase history and a pseudonymous account identifier that we generate. It does not receive your email address or your name.

When you delete your account, we ask RevenueCat to delete the customer record it holds for you, and we record whether that request succeeded. If RevenueCat cannot be reached at that moment the request is retried; it is not dropped.

Deleting your account does not cancel your subscription. A subscription bought through an app store is held by that store, not by us, and only you can cancel it there — deleting your account here will not stop the billing. See the data deletion page for where to do that.

Map tiles

Map tiles are served by MapTiler. Like any web server, it receives your IP address when your device requests a tile. MapTiler’s privacy policy states that it may use IP addresses for security checks, and that it processes them for that purpose for up to 2 months.

Public posts we read, including Threads

Some map entries come from posts that players published publicly themselves — a photograph of the in-game Detector with a place name in the caption. Decor Map reads those posts so a moderator can review the claim and, with attribution and a link back to the original, consider placing a pin.

Threads is one of these sources. Where Threads is used, posts are obtained only through Meta’s official Threads API, under the API terms and with the permissions Meta has granted. Decor Map does not crawl threads.com or any Threads web page; that is refused in code before a request is built, not merely discouraged by policy. Automated Threads search is currently not enabled: the permission has not been granted, no search has ever run, and no Threads post has been retrieved by this method.

For a matching public post, we may retain:

• The post ID and permalink — to deduplicate, to attribute the claim, and so every viewer can follow the link to the original post.
• An excerpt of the public post text, capped in length — the location claim itself, which is what a moderator reviews. We do not store the full post body.
• The post timestamp and language — how old a sighting is, and which moderator can read it.
• A pseudonymous per-author key — because counting independent sources requires knowing that two posts came from one account. We do not store the author’s display name, profile data, follower counts, or engagement metrics.

Images from public posts, and how long we keep them

The most useful part of a location report is usually the picture. Where a public post carries images, Decor Map may fetch them only from the media URLs the official API itself returned, over a transport restricted to the platform’s own media hosts.

• The original image bytes are stored privately and temporarily. They are held in private processing storage against a deletion deadline — 24 hours by default — which an automated expiry job enforces. They are not public, not served to visitors, and not part of the map.
• After that deadline, only derived information survives: a SHA-256 digest of the bytes, a coarse duplicate hint, the image dimensions and byte size, the content type, the structured result of the analysis, and evidence pointers recording which span of text or which region of the image supports each extracted value. These are kept for provenance and to stop the same photograph counting as several independent reports.
• Analysis extracts only explicit, visible facts — a place name, an address, a coordinate written as text, a station exit, a decor label, a visible date. A value the analysis cannot point at is discarded. We do not infer a location from scenery, and we do not turn a venue type into a claim about what the game yields there.
• No image is presented as ours. Source images never appear on the public map or in marketing, are never redistributed or exported, and are shown only to a signed-in moderator checking an extraction — beside the author’s permalink.
• Signed media URLs and access tokens are never written to logs.

No production vision or OCR provider is configured at present. Claims that would depend on reading text inside an image are therefore held as awaiting media analysis rather than being treated as read — and never as “nothing was there”.

Nothing publishes itself

No result from any public source is published automatically. Every candidate reaches a human moderator, who sees the excerpt, the permalink, the extracted location and every warning the pipeline raised, and who must record a reason. A pin also has to pass the trust rules before it is shown at all. Trust states are derived by the service from immutable evidence; no client can set one.

Where data lives

Application data is stored in a managed PostgreSQL database (Supabase, Singapore region) and the services run on Railway. Locale and session preferences live in your browser (localStorage and a locale cookie). In local development builds, all data stays in a PostgreSQL database on the machine running the stack.

Advertising, subscription and map-tile processing happens at the third parties named above — Google, RevenueCat and MapTiler — under their own policies, and not on our infrastructure.

Retention and deletion

• Your account and contributions. Request an export or deletion from Settings → Data, or by the contact route on our data deletion page. Deletion removes your account, your saved items and your collection, and detaches your identity from contributions that the map still depends on.
• Original images from public posts. Deleted automatically at the retention deadline described above.
• Hunt planner cache entries. A cached reply stops being used 24 hours after it is written. Expired entries remain stored until they are deleted; there is no automated purge for them today.
• Evidence records. Evidence is append-only and is withdrawn rather than silently erased, so that a correction has a recorded reason. A withdrawn source stops supporting a pin, and a pin left without support is retired.
• A post deleted at its source. If a post we previously retrieved is later gone, that is treated as removal and the record is tombstoned. Absence from a search listing is not treated as deletion, because it is not one.

If you wrote a post we used

If you are the author of a public post that Decor Map has used as a source and you want it removed, tell us and we will withdraw it. You do not need an account here, and you do not have to explain why. See the data deletion page for how to reach us and what happens next. Withdrawal removes your post as a source; a pin that depended on it alone is retired with it.

Platform data-deletion requirements

Where Decor Map reads data from a platform such as Meta’s Threads API, we honour that platform’s deletion requirements as well as this policy. That means: acting on a deletion or removal request we receive through the platform or directly; tombstoning records for content that has been deleted at source; deleting downloaded media on the retention schedule above; and providing the publicly reachable deletion route at /data-deletion, which needs no login. Where a platform’s terms are stricter than this policy, the platform’s terms apply.

Your choices

• Use the map without any account.
• Use a guest session and upgrade later — or never.
• Request an export or deletion of your data from Settings → Data. Where an automated endpoint is not available yet, the page says so honestly rather than pretending.

Changes to this policy

Material changes are dated at the top of this page. Where a new source or a new kind of processing is added, this policy is updated before that processing begins, not after.