Privacy

What we hold, and for how long.

Last updated October 28, 2026. Get This Shot is run by Matano Enterprises LLC. This explains the information used by our website and iPhone app.

Guests

A guest can join without creating an account. When someone scans an event code we create a record for them and put a cookie on their phone so the same device is recognised next time. That record holds a name and a table if they chose to give one, both optional and both editable. We also associate their contributions, favorites, hunt progress, and safety reports with an event-specific guest identifier.

Guests can join without giving us an email address, phone number or date of birth. A host may enter an email address to send that person an event invitation. We use it only to deliver that invitation through Resend and prevent repeat sends for the same event. The address stays with the event record and is removed when that event is deleted. We do not add invitees to a marketing list. Guest pages carry no advertising or analytics trackers, and there is no third-party script on any guest screen.

Photos, clips and messages

What a guest adds goes to the host's album for that event. We store the original exactly as it arrived and generate two smaller copies for display. We read the capture time and the dimensions from the file so the album can sort itself.

Photos also get an automatic quality check for blur and for near-duplicates. It runs on our own servers, produces a score, and decides only whether a photo waits for the host to look at it. Nothing is sent to a third party for this, and it is not face recognition: we do not detect, group, match or identify faces, and we hold no biometric data of any kind.

A fifteen-second message can be viewed or saved only by the event owner and any co-hosts the owner allows to access private messages. Co-host access is off by default and the owner can turn it off again. Messages do not appear in the album, on the leaderboard, or on a venue screen. The number of messages is public; the messages are not.

Who can see an album

Anyone holding the event link can see that event's album. The code is eight characters and is not guessable in practice, but it is a link: whoever it is shared with can open it. A host can add a passcode. We ask search engines not to index album, card or event pages, and we set a no-index header on them.

What a host is shown

The host of an event, and anyone they make a co-host, can see totals for their album: how many photos it holds, how many times it was opened, how many hearts and comments it has, and similar counts. They are running totals and are never broken down by person. Opening an album without signing in adds one to a total and stores nothing about you.

If you are signed in when you open somebody else's album, we note once that your account opened it, with the day you first did, so the host can see how many signed in people opened their album. We keep no time of day, no count of later visits and nothing else about the visit. The host sees only the number, never who. The note is deleted when the album is deleted or when you delete your account.

Hosts

A host account holds an email address, optionally a name, and if they sign in with Apple or Google, the account identifier that provider gives us. We use the email address to send sign-in links and notices about their own events. We do not send marketing to it or sell it. Our service providers process it only to operate the service. Hosts may also save a profile photo, event details, and custom hunt prompts.

Studio beta requests

If you ask for a Studio beta invite, we keep your name, email address, studio name, the rough number of shoots you chose and your website if you add one, and use them only to review your request and email you about it.

How long we keep things

Hosting runs 90 days for a free event and a year for a paid one. We email the host thirty days and seven days before it ends. On the date the album comes off the web and nothing is deleted. For a further year we keep the files, and the host can ask us at any point in that year to put the album back. After that year we delete them, and deletion means the files are removed from our storage rather than hidden.

Downloading everything at full size is free on every tier and available the whole time, so the end of hosting is never the moment somebody loses their photos.

A host can remove individual photos from the album. Deleted photos may remain in recovery storage for up to 30 days.

Deleting your account

Use Delete account in your web profile or the app’s Me tab. We remove your account, hosted albums and their photos within 30 days, and revoke linked Apple authorization. We may ask you to sign in with Apple again to securely complete that revocation. Restricted database backups expire within 90 days. Required payment records may remain with our payment provider. Guests can contact us to request removal of their contributions.

Who we use

Cloudflare hosts the service and stores the files. Resend sends our email. Stripe handles website payments, and Apple handles in-app plan purchases on iPhone. Card details go to the payment provider and never reach us. Apple and Google also handle authentication when you choose their sign-in options. Google Analytics and Microsoft Clarity measure how our public pages are used, and Meta provides advertising measurement for those same pages. The website no longer uses HeyCatch. The iPhone app uses Google Analytics and PostHog where configured for its environment, only after host sign-in. Older app versions may still use HeyCatch for hosts. Firebase Crashlytics, from Google, receives crash reports from the current iPhone app. PostHog measures how signed in hosts use the host dashboard on the website. All of it is described below.

Service activity and security

We retain purchase and refund records to apply event plans and handle billing. For an in-app purchase, the app sends us the Apple transaction identifier and the event it is for. We verify the transaction with Apple, then record the plan and payment status for that event. Apple handles in-app payment details and refunds; website card details are entered at Stripe's checkout. We do not store card numbers.

We use IP-based, short-lived request counters to limit abuse, along with server request timing, status codes, and error information to keep the service working. Diagnostic records can include internal account or event identifiers. We do not use these records for advertising. When enabled, website error reports are sent to Sentry. Event codes and access tokens are removed from those reports, and we do not intentionally include guest names or contributed photos or videos.

How you found us

When you arrive through one of our short links, such as getthisshot.com/ig from a link in one of our profiles, or through a newly generated event QR, we store a source word in a cookie on your device for 30 days. The cookie holds only that source token, for example "ig" or "utm_event_qr". It carries no identifier, no account, and nothing taken from your device or your visit, so it cannot tell you apart from anyone else who arrived the same way and cannot follow you to another website. If you later create a host account, we copy that word onto the account once, so we know which link brought new hosts. It is never used for advertising and never shared.

We count opens of our short links, newly generated event QR links and event pages in daily totals. We also count public page opens and, when the browser provides one, retain only the referring website's domain. These totals do not contain a visitor identifier, IP address, or full referring URL. QR opens can include repeat scans and link previews. Account signups by source are reported separately. Older QR codes that point directly to an event cannot be distinguished from other event links.

We also count page views with Cloudflare Web Analytics on our public marketing pages only, never on an event, album or host page. It sets no cookie and does not identify visitors.

Counting visits

On our public marketing and legal pages, the ones anybody can reach without an event link, we use Google Analytics. It sets cookies in your browser and sends Google the address of the page you opened, an approximate location worked out from your IP address, and what kind of device and browser you are on. We do not use it for advertising and none of its advertising features are switched on.

On those same pages we also use Microsoft Clarity, which records how the page was used: where you clicked, how far you scrolled, how the pointer moved, and the same sort of page, device and approximate location detail. Those recordings are played back and added up so we can see where a page confuses people. It sets cookies. Text you type is masked before it leaves your browser, so what reaches Microsoft is the shape of a visit rather than its contents, and we do not use it for advertising.

The website no longer uses HeyCatch. Older iPhone app versions may still use HeyCatch for hosts. The updated app uses PostHog where configured, as described under Measuring the iPhone app below.

None of those analytics or advertising tags is on event, album, hunt, message, host or back office pages on the web. We count event page opens only in the anonymous daily totals described above. Our public marketing, pricing, help, support and legal pages offer an optional support chat provided by 3CX; opening one of those pages loads its chat widget, and its provider may receive the address of that page. The chat never loads on a guest screen: event, album, hunt, message, TV, reel and photographer pages have no third-party script. Host and back office dashboards do not load the chat widget.

Measuring the iPhone app

The app is measured differently from the website, and only for hosts. Nothing is measured until you are signed in as a host. Before that, and for anyone who only ever scans a card and adds photos, the app measures nothing. Crash reports are separate and cover everyone who uses the app; they are described under Crash reports from the iPhone app below.

Once you are signed in we use Google Analytics and PostHog where configured for that app environment. Between them they are told the name of the host screen you opened, which is one of Create event, Events, Manage event and Account; that you created an event, and which kind it was, a wedding, a party or a game. We also measure creation and App Store checkout attempts and their outcomes, and visits to host features such as plans, stats, invitations, photo review and reels. Automatic screen capture, replay and lifecycle capture are disabled for PostHog. Analytics services receive network requests and can see the network address used to send them. Older installed versions of the app may still send HeyCatch data until they're updated.

We do not send either service your name, email address, account number, or anything you typed. PostHog receives a stable opaque host reference and, for gallery-specific host actions, an opaque gallery reference. These references let us relate feature use to the corresponding account and gallery within our own service; they contain no names, email addresses, event codes or private links. Google Analytics uses an app installation identifier. The app does not ask for permission to track you across other companies' apps and websites, because it does not do that: it carries no advertising identifier and none of the advertising components those services offer.

Nothing a guest does in the app is measured. Not the camera, not reviewing a photo, not the album, not the hunt, not joining an event. Those screens report nothing, and the automatic screen-by-screen reporting both services offer is switched off, so a screen is counted only where we have written it down by name.

You can turn it off. Me, then the measurement switch. Turning it off stops new collection on every launch afterwards, and it deletes what was already gathered on that device, including local analytics identifiers and queued PostHog events. Requests already in flight may finish; this does not delete records already received by a service. Signing out or switching accounts resets the local PostHog identity. It is on to begin with, which is the same as the website, where we measure unless your browser asks us not to.

If you would rather not be counted, most browsers can block these scripts, Google publishes an opt out add on at tools.google.com/dlpage/gaoptout, and Microsoft explains Clarity and how to opt out at clarity.microsoft.com/terms. Browsers set to Global Privacy Control are honoured on these pages.

Crash reports from the iPhone app

If the current iPhone app closes unexpectedly, it sends a crash report to Firebase Crashlytics, a Google service. This covers everyone who uses the app, guests included. A crash can happen on any screen, so crash reporting starts when the app opens, not at sign in.

A crash report holds the technical details of the crash: where in the app's code it happened, the app version, the device model, the iOS version, free memory and storage, and the time. Crashlytics gives each installation of the app a random identifier so that repeated crashes on one device can be grouped, and it can see the network address that sends the report. For a signed in host with measurement on, a report can also carry the recent host screen and feature events described under Measuring the iPhone app. We do not attach photos, clips, messages, event names or codes, names or email addresses, and we do not link a crash report to your account.

Crash reports are sent only by app builds connected to our live service, not by our test builds, and older installed versions of the app do not send them. Firebase keeps a crash report for 90 days. You can turn crash reports off: Me, then Share crash reports. The change takes effect the next time you open the app.

Advertising

On those same public marketing and legal pages, and nowhere else, we use the Meta pixel. Unlike the three above it, this one is for advertising rather than measurement. It tells Meta that a browser opened a page of ours, so that we can show ads to people who have already heard of us and see whether those ads led anywhere. It sets cookies, and Meta may match the visit to a Facebook or Instagram account it already holds.

When somebody buys a plan we also report that sale to Meta from our own server rather than from a browser, so an ad can be credited for it. That report contains the amount, the plan name, and the buyer's email address in hashed form, which lets Meta match an account it already has without us handing over the address itself. It never contains an event code, a photo, a guest, or anything a guest did.

Under some state privacy laws this counts as sharing personal information for advertising. If your browser sends a Global Privacy Control signal we load no pixel for you, and if you go on to buy something we do not report that sale to Meta either. You can also just ask us to stop, at hello@getthisshot.com. Meta explains its own controls at facebook.com/privacy/policy.

None of this runs on an event, album, hunt, message, host or back office page. A guest never meets it at all.

Asking us for something

Write to hello@getthisshot.com and we will act on it. That includes a host asking for their account and every event on it to be deleted, and a guest asking us to remove a photo of them or a record we hold about them. A guest who was at an event and wants something gone should say which event and roughly when, because with no account there is nothing else for us to look them up by.

Children

Get This Shot is for the person running an event, who we expect to be an adult. Guests at an event may be any age, which is exactly why nothing here profiles a guest, targets advertising, or does anything with faces.

Changes

If this changes in a way that matters we will tell hosts by email rather than quietly editing the date at the top.