gOGig Executor

Applies to the Android app in.gogig.executor (“gOGig Executor”, “the app”). Effective 12 August 2026. Last updated 23 September 2026.

gOGig Executor is a work app for field executors. You pick up a branding campaign, go to the site, capture photo or video proof that you were there, and submit it. Everything the app collects exists to make that proof verifiable and to pay you for it. There is no advertising in this app and no advertising identifier. The app does measure how it is used (see “App usage measurement” in section 1), but that measurement is about the app, not about you, and it is never used to profile or advertise to you.

1. What we collect

Data	Why	When
Phone number	It is your login. Sign-in is a one-time password (OTP) sent to it.	At sign-in
Name, role, executor ID	Identifies whose work a submission is, and who gets paid for it.	Returned by our server after sign-in
Precise location (GPS)	Checks you are inside the task’s geofence, and is written into each capture as proof of place.	Only while a capture or task screen is open
Photos and videos you capture	They are the deliverable: the proof of the completed task.	When you take them in the app
Audio	Only as the sound track of a video you record. The app never records audio on its own.	While recording a video
Capture metadata	Time, GPS coordinates and accuracy, camera direction, zoom, torch, device make and model, Android version, time zone, whether the device clock is network-set, and the app build. All of it is written into each file so a disputed capture can answer questions on its own.	At capture and at upload
Task answers	The form fields of the task you complete. What these are is set by the campaign: for example a shop name, a vehicle’s registration number, a measurement, or a survey the client asked for.	On submission
App usage measurement	Counts of how the app is used: that a task was submitted (with its campaign, the kind of campaign, whether it went up straight away or later from the upload queue, and how many files it had), that a task was saved on the phone to upload later, that a task could not be uploaded (with the kind of failure), that you signed in, which screens of the app were opened, and, for camera tasks, how many shots you took and how many you retook. It tells us how much work is being submitted, on which app versions, where uploads get stuck and which campaigns are hard to photograph. It carries no name, phone number, executor ID, location, or image. What Firebase records alongside it is set out below.	After a task is successfully submitted
App and device diagnostics	App version, device make and model, Android version, screen size, locale, network type, free disk space, battery and power-save state, how many uploads are queued, and recent app logs. Your name and account ID are attached, so support can tell whose phone a report came from without having to ask.	When you send a problem report, and automatically after a crash or an upload that could not be sent (see section 5)

Data

Why

When

Phone number

It is your login. Sign-in is a one-time password (OTP) sent to it.

At sign-in

Name, role, executor ID

Identifies whose work a submission is, and who gets paid for it.

Returned by our server after sign-in

Precise location (GPS)

Checks you are inside the task’s geofence, and is written into each capture as proof of place.

Only while a capture or task screen is open

Photos and videos you capture

They are the deliverable: the proof of the completed task.

When you take them in the app

Audio

Only as the sound track of a video you record. The app never records audio on its own.

While recording a video

Capture metadata

Time, GPS coordinates and accuracy, camera direction, zoom, torch, device make and model, Android version, time zone, whether the device clock is network-set, and the app build. All of it is written into each file so a disputed capture can answer questions on its own.

At capture and at upload

Task answers

The form fields of the task you complete. What these are is set by the campaign: for example a shop name, a vehicle’s registration number, a measurement, or a survey the client asked for.

On submission

App usage measurement

Counts of how the app is used: that a task was submitted (with its campaign, the kind of campaign, whether it went up straight away or later from the upload queue, and how many files it had), that a task was saved on the phone to upload later, that a task could not be uploaded (with the kind of failure), that you signed in, which screens of the app were opened, and, for camera tasks, how many shots you took and how many you retook. It tells us how much work is being submitted, on which app versions, where uploads get stuck and which campaigns are hard to photograph. It carries no name, phone number, executor ID, location, or image. What Firebase records alongside it is set out below.

After a task is successfully submitted

App and device diagnostics

App version, device make and model, Android version, screen size, locale, network type, free disk space, battery and power-save state, how many uploads are queued, and recent app logs. Your name and account ID are attached, so support can tell whose phone a report came from without having to ask.

When you send a problem report, and automatically after a crash or an upload that could not be sent (see section 5)

Location, specifically

The app requests precise location because a task is a claim that you were at a particular place. The coordinate is used to check the task’s geofence and is embedded in the photo or video you capture.

The app does not request background location. It cannot read your location when it is closed or in the background. Android’s background location permission is not declared in the app at all. Location is read only while you have a capture or task screen open.

Two things turn a coordinate into something readable, and both are worth naming. The app asks Android’s own geocoding service to turn your coordinate into an area name (“Bank More, Dhanbad”) for the line shown on the camera screen; on most handsets that service is provided by Google. And when a task shows you a map of a geofence you are outside, the map’s tiles are fetched from OpenStreetMap’s public tile servers, which necessarily see your device’s IP address and which part of the world you are looking at. Neither receives your name, your phone number or your captures.

Your profile, specifically

Signing in needs only your mobile number and the code sent to it. Everything else on your profile, meaning your name, a profile photo and your date of birth, is optional, added by you from the Profile screen, and stored with your account so the people who assign and review your work can see who did it. The photo is one you pick through Android’s photo picker, which gives the app that one image and nothing else from your gallery.

Camera and media, specifically

The app opens the camera to capture task proof. It does not browse, read, or upload your photo gallery, and it does not declare the Android media-read permissions that would let it. Only files you capture for a task are uploaded.

GPS Cam, which the app offers on its home screen, is a camera for your own use. Each photo is stamped with the gOGig logo, the address, coordinates, accuracy, date and time, the direction the camera faced, a Plus Code worked out on the phone, a small map of the spot, and any note you type, and saved to your phone’s gallery in Pictures/gOGig GPS Cam. Those photos are not uploaded and are not sent to us; the only things that leave the phone are the address lookup and the map thumbnail’s tiles from OpenStreetMap, both described under location above. On Android 9 and older, adding a photo to the gallery needs Android’s storage-write permission, which the app declares for those versions only and uses only for that. It still does not read your gallery.

Some campaigns ask the app to read a number off the photo for you, such as a vehicle registration plate or a serial code on a board, instead of making you type it. When that happens the photo, with the coordinate and the job type, is sent to our detection service at detection.gogig.in, which returns the text it read. It is an assist and it can be overruled: if the read is wrong or the service cannot be reached, you type the value in and the task submits exactly as it would have.

Your phone number and your SIM, specifically

Sign-in is restricted to a number your handset’s own SIM answers to, so that an account cannot be signed into from somebody else’s phone. To offer you that number the app reads the numbers on the SIMs in the device, which is what the phone permission is for. That read stays on the device: nothing about your SIMs, your slots or your carrier is sent to us or stored. The only number that leaves the phone is the one you pick and sign in with.

Auto-filling the OTP uses Google Play Services’ SMS User Consent API. Play Services watches for a single incoming message containing a code and shows you a prompt; only if you tap it does the app see that one message. The app does not hold any SMS permission and cannot read your messages.

App usage measurement, specifically

The measurement in the table is sent through Google Analytics for Firebase as a short list of events: a task submitted, a task saved to upload later, a task that could not be uploaded, a sign-in, a screen opened, and, after a camera task is accepted, the number of shots taken and retaken. Each carries at most a campaign id, the kind of campaign, the task’s id on our server, a count, a failure kind, or the name of a screen in the app. None carries a name, phone number, executor ID, GPS coordinate, or image.

Alongside it, Firebase records what it records for every app that uses it: that the app was opened, updated or removed, how long a session lasted, and the device model, Android version, app version and language it happened on. It also derives an approximate region, at country level, from the IP address the request arrives on. That is not the GPS location the app reads for a task; the coordinate on a capture is never sent to Firebase.

To join those records together Firebase generates an app-instance ID: a random number belonging to this installation of this app. It is not your advertising ID, not your Android ID, and not tied to your name or your phone number. The app switches the first two off by name. It is reset if you clear the app’s data or reinstall it, and it cannot be switched off while the measurement runs at all. This policy says so rather than claiming a measurement that leaves no trace.

None of it is used to advertise to you, to build an audience, or to follow you into another app. Ad-personalisation signals are switched off at the same place. It answers operational questions: how many tasks are being submitted and on which app versions, where uploads get stuck, which parts of the app are used, and which campaigns are hard to photograph, so the app and the instructions can be fixed.

The app also asks Firebase Remote Config, about once an hour, for one setting: the oldest app version still allowed to run, so a version with a known fault can be retired without waiting for everyone to update. That request carries a Firebase installation ID (a random number for this installation, reset on reinstall), the app’s own id and version, and the phone’s language and country setting. It carries nothing about you or your tasks.

2. What we do not collect

No advertising ID, and no ads anywhere in the app.
No attribution or cross-app tracking SDKs, and nothing that follows you between apps or websites.
The app usage measurement described in section 1 uses Google Analytics for Firebase. Advertising-ID collection, Android-ID collection and ad-personalisation signals are all switched off in this app, so the measurement cannot be used to advertise to you or to recognise your handset across apps. What it does record, namely the events and the app-instance ID Firebase attaches to them, is set out in full under “App usage measurement, specifically” above. The events carry no name, phone number, executor ID, GPS coordinate, or image.
No contacts, SMS, or call logs. Those permissions are not declared.
No background location.
No reading of your photo gallery or of files outside the app. GPS Cam only adds its own photos to the gallery.
No list of other apps installed on your phone.
No push-messaging service. Every notification the app shows is generated on your own device: by the upload worker, and, on a campaign that runs all day, by the reminder to upload your activity photos. Nothing is sent to your phone from our servers, and the reminders are scheduled entirely on the device.
No software installed by the app. gOGig cannot download or install anything on your phone, and it holds no Android permission that would let it. When there is a newer version, it asks the Google Play Store app already on your device (see section 4).

3. How your data is used

To sign you in and keep your session valid.
To show you the campaigns and tasks assigned to you.
To verify that a submitted task was captured at the right place and time.
To process payment for verified work.
To notify you about your uploads and your work.
To investigate a problem you report, to fix crashes, and to detect fraudulent or duplicated submissions.
To measure how well the app itself works, for example how many attempts a campaign’s photo takes, so it can be improved.

We do not use your data for advertising or marketing profiling, and we do not sell it.

4. Who we share it with

We do not sell, rent, or trade your personal information. We disclose it only in these cases:

Service providers who host and operate the platform on our behalf (hosting, storage, SMS delivery for the OTP), bound to use it only for that purpose.
The client whose campaign you worked on, where the task proof itself, meaning the capture with its location and time, is the deliverable they commissioned. This is the work product, not your account details.
When the law requires it, or to establish, exercise, or defend a legal claim, including investigating fraud.

Some third parties are contacted by the app itself rather than by us, and each is described in section 1: Android’s geocoding service, for the area name shown on the camera screen; OpenStreetMap’s tile servers, for the map drawn when you are outside a task’s geofence; and Google Analytics for Firebase, which receives the app usage measurement (the task, sign-in and screen events described in section 1) together with the app-instance ID and the device facts described in section 1. Google Play Services handles the OTP auto-fill prompt on your device, and the Google Play Store app is asked whether a newer version of gOGig exists, and does the downloading and installing if you accept. That exchange is between your phone and Google, under Google’s own privacy policy and the Play account already signed in on the device; we add nothing about you or your work to it, and we are not told the answer. None of them is sent your account details or your captures.

5. Diagnostics, problem reports, and crashes

When you send a problem report from the app’s menu, it carries the app’s recent log lines together with the device and queue facts listed in section 1, so that support can act on it without a phone call. Anything that looks like a login token or an inline image is stripped out of those logs before they are sent.

Every report says who it came from. Your name, your account ID and your role are attached to it, the ones already held on your device from when you signed in. A report that nobody can trace back to an executor cannot be answered, and the alternative was support guessing from a campaign name in the logs. It is the same information the app already sends when you submit work, and it is used to answer the problem, not for anything else.

Three things are reported without being asked for. If the app closes unexpectedly, it writes the error and the log lines around it to a file on your device and sends that file the next time it has a network, then deletes it. If a completed task cannot be uploaded, whether from no signal, a full phone, or a server that refuses it, the app files one report about that failure on its own, so that work stuck on a phone is something we find out about rather than something you have to tell us. The same goes for a capture the phone could not encrypt before queuing it: that report names the task and the file, not what is in it. And if your phone reports a location that Android marks as simulated, from a mock-location or “fake GPS” app, the app refuses the reading, tells you so on screen, and files a report about it. That report carries the coordinate the other app claimed, because a location that was refused is the only evidence that it was.

Repeats of any of the three are counted and sent as one report rather than one per attempt.

None of them carries your captures. Each carries the same technical information as a report you send by hand: what the app was doing, on what device, and which task could not be sent.

6. How your data is protected

Every request the app makes is HTTPS. Plain-text traffic is disabled at the app level, so an unencrypted request fails rather than silently going out in the clear. The app trusts only the certificate authorities that ship with Android, not ones added to the device later, so a network that tries to sit in the middle of the connection is refused rather than trusted.
Captures waiting in the offline queue are encrypted on the device with AES-GCM using a key held in the Android Keystore, hardware-backed where the phone supports it. Your session tokens are stored the same way. If the phone cannot encrypt a capture, because its storage is full or it runs out of memory, the capture is queued unencrypted in the app’s private storage rather than lost, and is encrypted the next time the app starts. Any unencrypted capture left over is deleted the first time the app starts after it is seven days old.
Android’s automatic cloud backup is turned off for this app, so queued captures and session tokens never leave the device through it.
Access to submitted data on our side is limited to staff who need it to run campaigns and payments.

No system is perfectly secure, and we do not claim otherwise. If a breach affects your data, we will notify you and the relevant authority as the law requires.

7. How long it is kept

On your phone: a capture stays on the device until it has been uploaded and the server has confirmed it, and then for as long as it is among the twenty most recent tasks of its campaign; past that the app releases the file to free up storage and the task still opens, fetched from the server. Videos are never released this way. Nothing that has not reached the server is ever deleted automatically. An unsent capture is the only copy there is, and the app treats it that way.
On our servers: task submissions and their proof are kept for as long as the campaign and its payment and audit records require, and afterwards for as long as the law obliges us to keep financial records.
Problem reports and crash reports: kept while the issue is open and for a reasonable period afterwards for support history.
The app usage measurement: held by Google Analytics for the retention period configured on our Analytics property, which cannot exceed the fourteen months Google Analytics allows for app event data. After that only aggregate totals remain.

Uninstalling the app removes everything the app stored on the device, including anything still queued and unsent. On Android 10 and later, the system uninstall screen may offer a “Keep app data” option; if you tick it, that data stays on the device (still encrypted and private to the app) so a reinstall of the app can pick it up again. It is off unless you choose it.

8. Your rights and choices

You can withdraw the camera, location or phone permission at any time in Android Settings. The app will keep working, but tasks that need a verified place or a capture cannot be completed without them, because that verification is what the task is.

You can also ask us to:

tell you what personal data of yours we hold;
correct anything inaccurate;
delete your account and its data (see below);
have a grievance about your data addressed.

Write to support@gogig.in from the phone number you registered with, or name that number in your message. We respond within 30 days. Indian users have these rights under the Digital Personal Data Protection Act, 2023.

Deleting your account does not need an email at all. You can do it yourself at dashboard.gogig.in/delete-account. The next section says what happens when you do.

9. Account and data deletion

Delete it yourself: dashboard.gogig.in/delete-account. Sign in with the phone number on your account, confirm, and the request is filed without anybody having to read an email. The same page is linked from About inside the app.

Or write to us: email support@gogig.in with the subject “Delete my account”, from the email address on your account or naming your registered phone number. We verify the request against your registered number.

Either way, what is deleted is the same: your account, your profile details, and your submitted captures. Anything still waiting on your phone goes with the app when you uninstall it, unless you choose “Keep app data” on the uninstall screen.

We keep only what we are legally required to keep: payment and tax records for completed work, and any data under an active legal or fraud investigation. Those are retained for the statutory period and used for nothing else.

10. Children

gOGig Executor is a work app for adults engaged as field executors. It is not directed at children and we do not knowingly collect data from anyone under 18. If we learn that we have, we delete it.

11. Changes to this policy

If this policy changes, the updated version is posted at this address with a new “last updated” date. Material changes to what we collect or why will be communicated in the app before they take effect.

12. Contact

Questions, requests, or grievances about your data:

Email: support@gogig.in
Website: www.gogig.in

gOGig Executor · in.gogig.executor · Privacy policy, last updated 23 September 2026.