Privacy Policy

Anime Maps (“AnimeMaps”) manages information handled through its website and mobile application under this Privacy Policy.

Last updated: 2026-08-26

1. Operator and contact

Service: Anime Maps
Contact: animemapsx@gmail.com

2. Information we collect and store

• Account information: email address, login ID, display name, profile, bio, avatar, language, time zone and display preferences.
• Usage information: favorites, personal-calendar dates and categories, private notes and viewing history.
• Community information: ratings, comments, replies, likes, reports, support requests and operator responses.
• X and Instagram share information: the shared post’s source URL, shared text and a snapshot of event candidates produced during matching. These are stored with the share submission record to match events, confirm the candidate selected by the user and let operators handle unmatched submissions.
• Technical information: app version, OS, language, authentication sessions, connection data transformed for abuse prevention, and access logs produced by servers and infrastructure.
• Location: latitude and longitude submitted to the API when you use Nearby Events and included in its response. It is not designed for ongoing storage in your member profile, but coordinates may appear briefly in response caches, access logs or security logs. You can disable permission in device settings.

Purchases and subscriptions: when you purchase or restore through Apple App Store or Google Play, AnimeMaps sends RevenueCat a random billing customer ID that contains no email address. AnimeMaps stores the verified entitlement, product ID, store, production/sandbox environment, purchase, expiry and grace dates, renewal status, management URL and last verification time returned by RevenueCat. To prevent one purchase from being granted to multiple AnimeMaps accounts, we store a one-way, server-keyed HMAC fingerprint derived from the store transaction identifier. The AnimeMaps account database does not store the raw store transaction identifier, receipt, purchase token, card number or webhook body. For webhook idempotency it stores only the event ID, type, environment, product ID, pseudonymous billing customer ID, payload SHA-256 and processing state. Apple, Google and RevenueCat process the payment and their transaction records under their own terms.

Advertising and consent: the app first updates consent information through Google User Messaging Platform (UMP) and, where required, completes the consent or privacy-options flow. It requests an ad from Google Mobile Ads SDK (AdMob) only when the resulting UMP status permits it. The initial release requests non-personalized ads only. When ads are requested or shown, Google may process the IP address, device and app identifiers and settings, OS, language, approximate area inferred from the IP address, and ad impressions, clicks and other interactions for delivery, fraud prevention and measurement. AnimeMaps does not intentionally send the account email, favorites, private notes, purchase contents or precise location as ad-targeting data. Available consent and privacy choices can be changed from the supported app screen. While Premium is active, the app sends no ad requests. Google’s terms and privacy policy apply to Google’s processing.

AnimeMaps profiles are public. When you create or edit a profile, your user ID, display name, selected avatar, entered bio, and standard or Premium membership tier can be viewed by other users through the profile API without authentication. Product IDs, purchase Store, price, purchase date, renewal date and expiry are not included in the public profile. Entering a bio is optional, but any bio you enter is public. Published comments and replies show their body together with the author’s user ID, display name and avatar without requiring sign-in, and viewers can open the profile from the author’s icon or name; the bio is not included directly in comment author information. There is no setting to make a profile private. Do not enter personal or confidential information in a profile, comment or reply if you do not want it to be public.

To prevent spam in comments and replies, we process posting frequency; user and event identifiers; a keyed-HMAC fingerprint of the body; features such as URL count and repeated characters; a decision score and reason code; status (published, pending review or rejected); a request_id used to prevent duplicate submissions; and the count of operator-confirmed spam decisions and any posting block expiration. Dedicated anti-spam records do not store the raw IP address. Rate limiting uses a keyed HMAC identifier that changes each day. These HMAC identifiers do not display the original IP address or body, but they are pseudonymous information that can link the same source or body during their retention period. Separately, raw IP addresses may be recorded in web/CDN access logs or security logs.

Any comment or reply containing even one URL is rejected automatically. Its body is not published or sent for translation.

3. Purposes

We use information to provide and secure the service, authenticate users, personalize displays, synchronize favorites and calendars, operate and moderate the community, prevent abuse, answer support requests, translate content, investigate failures, and improve quality and safety. Spam classification runs only within the AnimeMaps WordPress server and account database; we do not send bodies or classification metadata to an additional external spam-classification service for this purpose. Clearly rejected and pending-review submissions are not sent to Google Apps Script or Google LanguageApp. A pending submission enters the translation queue described in Section 4 only after an operator approves and publishes it.

4. Automatic comment translation using Google

The full comment or reply text, source and target languages, source hash, one-time nonce, issued-at time, pseudonymous request ID and signature are sent by the AnimeMaps WordPress server to a Google Apps Script controlled by AnimeMaps and translated with Google LanguageApp. Account email, user ID, display name, favorites, private notes and current location are not attached to the translation request as separate fields. However, if a user writes a name, email address or other personal information in public comment text, that information is sent to Google as part of the full text. Do not put personal or confidential information in public comments. Google’s terms and privacy policy apply to Google’s processing.

5. Translation cache and retention

Original text and translated results are cached in the server database while the comment or reply remains, so the same text can be displayed without repeatedly sending it externally. An edit makes stale translations ineligible for display. Deleting or hiding a comment or reply removes its active translation cache and cancels its translation jobs. Separately, GAS temporarily stores translation results in Google Apps Script Script Cache for up to approximately six hours, after which they expire automatically (they may be evicted earlier because of capacity or other limits). Deleting or hiding a comment or reply does not let WordPress immediately erase this external temporary cache, so a result may remain until it expires. Technical metadata for completed and cancelled jobs is normally removed progressively after 30 days. Metadata needed for retries or failure investigation may remain until the issue is resolved.

6. Private notes

A favorite’s private note is returned only in its owner’s authenticated views. It is not included in public profiles, events, comments, calendar or image shares, or GAS translation. Notes are stored in the server database and backups, are not end-to-end encrypted, and may be accessed by operators where needed for maintenance, security, incident response or support. Do not enter passwords or other secrets. Removing a favorite also removes its note from the active database.

7. Calendar share links

Creating a calendar share makes a fixed snapshot containing the selected month and categories, event titles, scheduled dates, event start and end dates, and event images. Anyone who has the link can view it. The viewing period is at most 30 days from creation. Each user may have at most 20 active links; if a new link is created when that limit has been reached, the oldest active link may become unavailable before 30 days. A link can be revoked through a supported screen or the authenticated API. If the current app does not show a revoke control, contact the address above. Share links carefully. The active snapshot database row stores a hash instead of the link token itself, together with the owner’s user ID and the snapshot. However, the raw share link may be recorded in web/CDN access logs or security logs. Private notes are not included in the snapshot.

My Calendar push reminders: If you opt in to tomorrow reminders, we store a random installation identifier, the active Expo push token and its hash, platform, IANA time zone, locale, app version, notification settings, scheduled date and count, a pseudonymous event-set fingerprint, and technical job, ticket, receipt and error status. At send time we send the token, a localized public event title for one event or an aggregate count for several events, the scheduled date, and minimal tap data (notification type and scheduled date) to the Expo Push Service. Expo may pass the notification to Apple or Google’s push infrastructure. Private notes are never included in notification jobs, logs or external payloads. Turning reminders off clears all registered tokens; unregistering a device or logging out disables that device and cancels unsent work. The token is also disabled if the authentication session used to register it is revoked or expires. A token reported as DeviceNotRegistered is disabled immediately. Disabled device rows and completed, failed or cancelled technical metadata are normally removed progressively after 30 days. Receipts are normally checked from about 15 minutes after sending and treated as expired if unavailable after 24 hours. Backups age out through normal rotation. Authorized operators may access this information only where needed for maintenance, security, incident response or support.

The app keeps a random device-revocation secret for logout. On logout it sends the installation ID and this secret to AnimeMaps to request revocation. The server processes it for comparison, stores only its one-way HMAC hash, and never stores the raw secret. That HMAC may remain on the disabled-device row for up to 30 days so a delayed revocation retry can confirm completion.

A receipt status of ok confirms provider handoff, not delivery to or display on the device.

8. Storage, deletion and backups

Account information is retained while needed to maintain the account, and usage information while needed to provide features and operate the service safely. User deletion actions remove data from the active service database or erase its body as appropriate. A report’s reason, reporter-supplied details and snapshot of the reported body may remain in audit records after the original post is deleted or hidden. Records needed for security or legal matters may also be retained for a reasonable period. Backup copies are not deleted immediately; they age out through normal backup rotation and may temporarily reappear during disaster recovery.

The AnimeMaps billing customer mapping, verified entitlement and purchase-owner HMAC are retained while needed to associate the account and purchase safely, and are removed from the active database when the AnimeMaps account is deleted. Where a billing customer mapping exists, AnimeMaps also requests deletion of the corresponding RevenueCat customer profile. Minimal webhook replay records are normally deleted after 400 days; account deletion blanks the pseudonymous billing customer ID in those records. Purchase or transaction records retained by Apple, Google or RevenueCat for legal, accounting or fraud-prevention purposes are not erased by this process, and a store subscription is not cancelled automatically. A newly registered account receives a new billing customer ID, so automatic transfer or restoration of purchase access to a new account is not guaranteed.

Daily-HMAC rate signals expire logically by day and are normally removed by hourly cleanup within approximately 48 hours after logical expiry. A request_id idempotency record does not contain the body itself and retains only the body’s HMAC fingerprint and decision code for up to 30 days. A pending-review body, score and reasons are retained for operator review for up to 30 days; if no decision is made by expiry, its body is erased. Approval clears the review score and reasons, but while a post is public its body HMAC fingerprint remains with the post to prevent duplicate submissions to the same event; owner deletion or operator hiding clears it. Whether a pending post is approved or marked as spam, a body-free audit record of the operator action and reason codes is retained for up to 365 days. When an operator marks a post as spam, the body, post-side HMAC fingerprint, score and reasons are erased immediately. Operator-confirmed spam history (strikes) is retained for up to 365 days from the latest confirmation. Posting blocks escalate to 24 hours, 7 days or 30 days; after a block expires, blocked_until is retained only within the strike-retention period. An automatic hard rejection by itself does not add a strike. These periods support abuse prevention, appeals and failure investigation.

9. Service providers, disclosure and operator access

Hosting, email, translation and billing-verification providers may process information only as needed to provide those services. Apple, Google and RevenueCat process payment and purchase status for in-app purchases. We do not sell personal information.

We may disclose information with consent, when required by law, or when reasonably necessary to protect life, safety or the service. Authorized operators may access stored information where needed for service operations, maintenance, moderation, security, incident or support response, or legal compliance. This includes reviewing the body, score and reasons of a pending submission and deciding whether to approve and publish it or mark it as spam.

10. Security

We use reasonable measures such as access controls, encrypted transport, protected authentication tokens and separated privileges. No Internet transmission or storage system can be guaranteed absolutely secure.

11. Your choices and requests

Available app screens let you review, change or remove profile information, history settings, posts and favorites. You can delete the entire account after identity verification from Account > Settings > Delete account in the app or from “/account-deletion/” on the web. A monthly or yearly Store subscription is not cancelled automatically, so cancel it through Apple or Google Play before deletion. For other access, correction, deletion or account requests, contact the address above in a way that allows us to verify the account holder.

12. Changes

We may update this policy when features or data handling change. Material changes will be announced on the site or in the application.

13. Email verification, policy consent, user reports and blocks

New registration sends a time-limited six-digit email code. The database stores only a request ID, normalized email, one-way code HMAC, 15-minute expiry, resend time and at most five attempts—not the plaintext code or password. A completed registration request is normally deleted immediately. Any consumed request left after a deletion failure, and expired incomplete requests, are removed by an hourly bounded cleanup. The mail provider processes delivery data as necessary.

Before UGC, AnimeMaps stores the user ID, current Terms and Privacy Policy versions and acceptance time. User reports store reason, details, a reported display-name/bio snapshot, related comment, user IDs and status for authorized WordPress operator review. Blocks store both IDs and time and hide the target profile, comments and replies from the blocker’s authenticated views. Account deletion removes consent and blocks; retained reports anonymize the reporter and erase the deleted target ID, profile snapshot and related comment.

14. Support conversation history and response notifications

For an inquiry, AnimeMaps stores the ticket ID, category, status, original message, follow-up messages, operator responses, related event and report information, app build, OS and language, created, updated, answered and closed times, sender type and related user or operator IDs, an ID used to prevent duplicate submissions, email-notification status, attempt times and a minimal error code, and a cutoff time showing how far the inquiry history has been read. Each user and operator message is appended to the same inquiry without overwriting earlier messages or responses and is retained as history to handle the inquiry and verify its course. Authorized operators can review the history and respond in the WordPress admin screen.

When a user sends a new inquiry or follow-up, the notification email to the operations mailbox includes the message and ticket details. If you request notifications to your registered email, an email sent when an operator responds only announces that the response is available in the app; it contains no response text, and AnimeMaps does not set a Reply-To address. Send follow-up questions from Inquiry history in the app. Inquiry and message rows in the account database are deleted when the account is deleted, but sent email and backups are not erased immediately and may remain as described in this Policy’s provisions on storage, deletion and backups and on service providers. If an operator account is deleted, the response text is retained to preserve the conversation history and the operator sender ID is anonymized.

The unread count is the number of operator messages created after the cutoff time stored for each user. It is not a per-message read receipt and does not notify operators that a message has been read. Marking an inquiry Closed does not delete its history, and individual messages cannot be edited or deleted. For inquiry rate limits, AnimeMaps creates server-keyed HMAC identifiers from scope values such as the user ID or a valid IP address and does not store those original values directly in the rate-limit rows. A row expires logically when its one-hour fixed window ends, and old rows are deleted progressively in bounded batches. Separately, a raw IP address may be recorded in web/CDN access logs or security logs. A notification status of “accepted” means only that the sending process accepted the request; it does not guarantee actual delivery or display on a device or screen. Even when response notifications are not requested (reply_requested=false), the operations notification email for a new inquiry or follow-up includes its message body.