Privacy Policy

For customer account data (section 2), GeoPulse decides how the data is used.

For end-user data sent by the SDK (section 3), the customer who built the app decides why and how it is collected, and GeoPulse processes it on the customer's behalf, as a service provider. If you are an end user and have a question or request about your data, please contact the developer of the app first.

• Account details: your name and email address, and your sign-in credentials. Passwords are handled by Google Firebase Authentication; we never see or store them in readable form.
• What you configure: organizations, projects, applications, locations, geofences, rules, webhooks, campaigns and experiences, including webhook URLs. Webhook signing secrets and SDK keys are stored only in hashed or access-restricted form where the service doesn't need to read them back.
• Map and place search: when you search for a place or view a map in the portal, your search text and map requests go to Mapbox.

The SDK runs inside a customer's app. Geofence detection happens on the device. The SDK sends data to GeoPulse only when:

• the app starts (device registration): a random device identifier the SDK generates and stores on the device (not an advertising identifier), the platform (iOS or Android) and the SDK version; and
• a user enters or exits a geofence while the app is in the foreground: the precise latitude and longitude and the time of that moment, the geofence, location, application and device identifiers, and any metadata the customer attaches.

Continuous location readings stay on the device and are not uploaded. The SDK asks for foreground location only, never background location, and only with the user's permission through the operating system prompt.

The SDK also asks for any experiences (banners, cards) waiting for the device, and confirms when one has been shown. These requests carry the device identifier and the SDK key.

To protect the service from abuse we use IP addresses for short-lived, in-memory rate limiting, and we log basic request details (method, path, status, duration). Our hosting providers may also keep their own request logs, which can include IP addresses.

• To provide the service: store events, evaluate the customer's rules and campaigns, deliver webhooks and show data in the portal.
• To keep the service secure, reliable and within fair-use limits, and to fix problems.
• To contact customers about their account and the service.

We do not sell personal data, and we do not use end-user location data for advertising.

• The customer: event data is visible to the members of the customer's organization in the portal, and is sent to any webhook endpoint the customer configures. We have no control over what a customer does with data once it has been delivered to them.
• Service providers that run GeoPulse for us: Google (Firebase Authentication and Cloud Firestore, where data is stored), Render (backend hosting), our portal hosting provider, and Mapbox (maps and place search in the portal).
• Authorities or successors, where the law requires it, or in a merger or sale of the service, with notice to customers.

Account data is kept while the account exists. Event and device data is currently kept until the customer's project is removed or a deletion is requested; we do not yet delete it automatically on a schedule. To request deletion, email us at the address in section 12 below.

Data is sent over HTTPS. SDK keys are stored only as hashes. Each customer's data is isolated by organization and enforced by database access rules and server-side checks. No system is perfectly secure; if we learn of a breach affecting your data we will notify the affected customers.

If your app uses the SDK, you are responsible for telling your users that you collect precise location and a device identifier, for the reasons you collect them, and that GeoPulse processes them for you. Concretely:

• Describe this in your own privacy policy, and obtain consent where the law of your users' region requires it.
• Apple App Privacy: declare Precise Location and Device ID. Google Play Data safety: declare Approximate and Precise location and Device or other IDs. Choose the purposes that match how your app uses the data.
• Use a clear permission prompt text that explains why location is needed.

Our terms of service set out these responsibilities in full.

Depending on where you live, you may have the right to access, correct, delete or export your personal data, or to object to some uses. Customers can contact us directly. End users should contact the developer of the app they use; we will help the developer respond.

The service is for developers and is not directed to children. Customers must not use the SDK in apps directed to children without meeting the legal requirements that apply.

We will post changes here and update the date above; for material changes we will also notify customers. Questions, requests and complaints, email damncoding23@gmail.com. See also our Terms of Service.