Whit we ken aboot ye

The short version

We want to know whether Fan's Yer Bin? works — not who you are.

There are no accounts here, and no tracking cookies. The address you look up is saved on your device, not on our server.

Nearly every postcode is matched to its council on our own server, so it doesn't need to go to an outside postcode service.

We do count things — a lookup finishing, a share being used — but as totals, with nothing attached that says who you are.

The rest of this page is the detail behind those sentences, including the parts that are less tidy.

What we collect

During a search

What we do store

Offline app shell. The service worker keeps the generic app shell, clean pages you visit, and static icons/assets in your browser's Cache Storage so the site can open when the network is unavailable. It never caches /api/ requests or bin dates, and shared URLs carrying a postcode or UPRN are deliberately not stored as cache keys. Each deployment rotates to a new app cache; clearing site data removes it.

Last-searched address. If you've done a search before, your postcode, UPRN, and address label are also saved in localStorage so the app can auto-load your schedule next time. This stays on your device only. Clear your browser storage to remove it.

Collection schedule cache. Once your bin schedule has loaded, the collection dates are saved in localStorage. For the first 6 hours the app treats them as fresh and shows your schedule instantly on a repeat visit — no server request needed. After that it checks with the council again. While that check runs your saved dates stay on screen, drawn in a paler treatment that says they have not just been confirmed. If the council can't be reached at all, or answers but can't confirm your address that particular time, it will still show you dates saved in the last 7 days, and says which of the two happened rather than leaving you to guess. This data lives entirely on your device, is never sent to us, and is replaced on your next successful lookup or when you clear your browser storage.

Recent addresses. The last 5 addresses you looked up successfully (postcode, UPRN, and address label) are kept in localStorage so you can switch between them in one tap — handy for a second property or a relative's house. They stay on your device, are never sent to us, and each one can be removed individually with the ✕ beside it.

Home screen tip. On an iPhone or iPad we show a one-line tip explaining how to add the site to your home screen. If you dismiss it, a single flag in localStorage records that so it never comes back. It holds nothing about you — only that the tip was closed.

Seagull game. If you find the wee game hidden in the footer, your high score, number of flights, lifetime total bins dodged, how many different days you have flown and the date of the last one, your current and longest runs of flights that scored nothing, how many golden bins you have flown through, which gulls you have earned, which gull you chose, which gull unlocks you have already been shown, whether every gull has been made available on this device, whether you muted the sound, and whether you chose the Modern or Retro art are saved in localStorage too. Those exact values stay on your device. If you share a score, the link you send carries that score and whether it is your best, and nothing else about you.

We do count that the game was opened, started, ended, replayed, shared or left, that a link was copied, that the art was switched, that the Retro music started or was cut off, that a gull was unlocked or flown, and that every gull was made available — so we can tell whether it's worth keeping. Two of those carry a rough band rather than a number: your score as something like “5-9”, and how long you played as something like “10-30s”. The gull events name the gull and nothing else. Never your actual score, never a precise time, never your taps or key presses, and nothing that could tell one player from another.

How your postcode is handled

The short version: for almost every search, working out which council serves you happens on our own server — your postcode does not go to an outside postcode service to answer that. And if that outside service is having a bad day, your bin dates still work.

1. You type a postcode into the browser.
2. The app sends it to our server route.
3. Our server looks the postcode up in a map of Scottish postcodes that ships with the app, to work out which council area it falls in. This happens on our own server. Your postcode is not sent anywhere to answer it.
4. Armed with the correct council, our server queries that council's systems to find the addresses at your postcode.
5. You pick your address; the council returns your bin schedule.
6. The result is sent back to your browser and displayed.
7. The postcode is not written to an application database or permanent file by us.

That's it.

Why a map rather than the postcode number? Postcode-to-council boundaries don't follow simple numeric patterns. Fourteen of the thirty-four AB postcode districts are split between more than one council, so guessing from the number would send thousands of households the wrong bin dates. The AB area also reaches into Moray, Angus and Highland, which we don't cover — so “starts with AB” is not the same as “we can help”.

Where the map comes from: Ordnance Survey's Code-Point Open, a free, official dataset of every current postcode in Great Britain. We take the Scottish portion, keep only the postcode and the council that serves it, and ship it with the app — along with each council's official name, which comes from the same download. It's refreshed when Ordnance Survey publish a new release, roughly every three months.

Holding all of Scotland rather than just the north-east costs us very little and means one thing we care about: if your postcode is somewhere we don't cover, we can tell you which council does serve it straight away, without asking anyone else. Knowing who collects your bins is not the same as being able to show you the dates — see Coverage for the councils we can currently show dates for.

Contains OS data © Crown copyright and database right 2026. Contains Royal Mail data © Royal Mail copyright and database right 2026. Contains National Statistics data © Crown copyright and database right 2026.

Server-side caching

To avoid hammering the council systems with repeat requests, our server keeps a short-lived, in-memory cache. Here's exactly what that means:

• What's cached: The bin collection schedule for a given property reference (a UPRN for most councils, something narrower for a few — see “What we collect” above).
• What's not cached here: Your IP address, or anything identifying you. Your postcode is not part of this cache's key. A postcode our built-in map doesn't recognise is remembered separately for up to 24 hours, so we don't ask an outside service about it twice (see “Postcode routing” below).
• How long: 6 hours. After that, the entry is discarded and the council is queried fresh on the next request.
• Where: In the memory of the Vercel serverless function instance. This is not a database. It is not persisted to disk. When the instance shuts down or is replaced, the cache is gone.
• Who can see it: It is internal process memory, not a public data store.

For most councils that's a UPRN, publicly available information linked to an address, not a person — but for Moray and Clackmannanshire it's the council's own property number instead, and for Orkney it's a collection-area code covering many addresses, not a single one.

Automated health monitoring

A scheduled check runs a couple of times a day to make sure the council lookups still work (the councils occasionally change their websites and break things). It's deliberately gentle and privacy-preserving:

• What it checks: one public postcode per council, taking whichever property the council lists first. It has to be a normal residential postcode, because only a real kerbside schedule can prove the lookup still works. Nobody's address or property reference is written down: none is stored in our code, and the reports record only counts — how many addresses came back, and how many future dates.
• What it does with your searches: nothing — your searches are not logged, stored, or used by the monitoring.
• If a council's system breaks: we're alerted automatically and any diagnostic detail is sanitised (session tokens and property references stripped) before it's recorded. Meanwhile the app shows your last saved dates, clearly marked, rather than failing outright.

Third-party services

We use the following external services.

Vercel (hosting)

Fan's Yer Bin? is deployed on Vercel. Vercel handles the infrastructure, so its edge network processes incoming requests and may retain standard infrastructure or function-log metadata under its own privacy policy. We do not deliberately write postcodes, UPRNs, addresses, or analytics payloads into our application logs.

Three of them measure the site, and each answers a different question.

• Vercel Analytics — how many people use the site, and which pages.
• Vercel Speed Insights — whether it's fast, and where it isn't.
• GoatCounter — whether a feature is actually useful. It tells us what happened on the site, not who did it.

None of the three is given your postcode, your address, or your property reference.

Vercel Analytics

We use Vercel Analytics to measure page views and general traffic. It sets no cookies and builds no lasting identifier for you. Vercel counts a visitor using a privacy-focused hash made from the incoming request; that hash is valid for one day and then resets, so it cannot follow somebody across days or across different websites. The dashboard gives us aggregate page and visitor totals plus broad breakdowns such as referrer, country, browser, operating system, and device type — not a persistent visitor profile.

Before a page-view event leaves the browser, we remove any postcode, uprn, score or new query parameter from its URL. Shared lookup details and shared seagull scores therefore do not reach Vercel Analytics.

Vercel Speed Insights

We use Vercel Speed Insights to measure Core Web Vitals. Its data points can include the route/path, network speed, browser, device type, operating system, country, the measured Web Vital, and the HTML element associated with a performance issue. Vercel says these points are anonymous, are not tied to an individual visitor or IP address, and cannot reconstruct a browsing session across pages.

The same URL redaction applies here: postcode, uprn, score and new query parameters are removed before a performance event is sent.

GoatCounter (product analytics)

We use GoatCounter to count how the site is actually used — how often a lookup succeeds, how often a cooncil's system fails us, whether folk use the share or save buttons. It tells us where to spend our time. It's an open-source service run from Ireland.

Your browser never contacts GoatCounter. The counts are sent from our server, not from your device. That means no third-party script runs on the page, no cookie is set, and it stores nothing on your device — which is also why you see no cookie banner here.

What gets counted: an event name and the time it happened. The name carries a few fixed labels — which cooncil, whether the data was live or cached, why a postcode was rejected, roughly how many addresses came back. Every one of those is chosen from a short pre-agreed list, so it is a counter and nothing more: “lookup completed, Aberdeenshire, live” went up by one.

What never gets sent: your postcode, your address, your UPRN, your IP address, your browser's user-agent, your screen size, your language, or the page you came from. GoatCounter is sent none of those, so it has nothing to group your visits by and cannot build a profile even if it wanted to. If your browser sends a “Do Not Track” or Global Privacy Control signal, we send no product events at all. That signal stops these counters; it does not switch off Vercel's page-view and performance measurement described above.

Postcode routing (only for a postcode we don't recognise)

The map described above holds every Scottish postcode that existed when it was built, so nearly every search is answered on our own server and your postcode goes nowhere. Royal Mail creates new postcodes each month, mostly for new-build houses. If yours is newer than our map, we ask an outside postcode service rather than guess.

• This only happens for a postcode the built-in map doesn't hold. If you get your bin dates without an error, and your street isn't brand new, it almost certainly didn't happen.
• When it does, we ask postcodes.io and, if that doesn't answer quickly, findthatpostcode.uk as well. Both are free, open-data services built on the same official statistics. We use two so that one being down doesn't leave you stuck.
• They receive the postcode and nothing else. They return a council code. They do not receive your UPRN, your address, or anything about you.
• Their own handling is covered by the postcodes.io privacy policy and the findthatpostcode.uk privacy policy.

Postcode lookup cache: When an outside service does answer, our server remembers that one postcode→council mapping in memory for up to 24 hours, so we don't ask twice. It holds the postcode string and the council name — no user account or profile. It lives in process memory and is discarded when the server restarts. Postcodes answered by the built-in map never enter it, because there is nothing to remember.

Security-policy reports: The site tells your browser exactly which scripts and styles it's allowed to load. If something violates that policy, your browser posts a short report back to us naming the page and the blocked resource. It goes to our own server, not a third party, and it's there so we notice if anything unexpected ever tries to run on the site.

What we don't use

• Google Analytics
• Mixpanel, Amplitude, or any visitor-level behavioural profiling. We do count product actions — a lookup finishing, a share being used — but as totals, with no visitor attached
• Advertising networks or tracking pixels
• Session recording tools (Hotjar, FullStory, etc.)
• Third-party font or asset CDNs — every font is self-hosted from our own domain, and nothing is fetched from Google Fonts or similar

Data retention

How it compares to the official council websites

Security

• HTTPS everywhere. All traffic is served over HTTPS, and browsers are told (via HSTS) to refuse insecure connections in future. Your postcode and UPRN are encrypted in transit.
• Strict browser security headers. A Content Security Policy restricts where scripts, styles and images can come from; the site declines to be embedded in iframes on other origins; MIME-type sniffing is disabled; referrer data is minimised.
• Input validation. Every postcode and UPRN is checked against a strict format on the server before it's used — malformed or crafted inputs are rejected before they reach any upstream system.
• Abuse protection. The API endpoints that look up addresses and collection dates are rate-limited, with a firewall rule in front of them, so a single bad actor can't hammer the site or the council systems behind it. Keeping that count means briefly holding a request tally against your IP in memory for 60 seconds — it is never written to disk and never deliberately logged by the app. The count stops applying the moment it expires; the expired entry itself is cleared the next time that server tidies up, and always when the server restarts.
• No account database. There are no user accounts, passwords, customer profiles, or email list. Server-side state is limited to short-lived in-memory caches and abuse counters, while Vercel's infrastructure handles normal hosting metadata under its own policy.
• Kept current. Dependencies are updated regularly, and the codebase is periodically reviewed end-to-end for common web vulnerabilities (injection, cross-site scripting, SSRF, etc.). The most recent review was in August 2026.
• Infrastructure. Vercel provides DDoS protection and edge-level filtering at the infrastructure layer.

What we can and can't guarantee

We can guarantee

• No user accounts, advertising profile, or customer database.
• No tracking cookies, advertising pixels, or persistent cross-site identifier set by us.
• The schedule cache contains only property references (a UPRN for most councils, something narrower for a few — see “What we collect” above) paired with bin schedules, never a name or user account.
• Postcode, UPRN and shared-score query parameters are removed before Vercel observability events are sent.
• Honest updates to this document if any of the above changes.

Outside our control

• Some addresses have no regular schedule. Communal bin stores, on-demand collections, and privately-managed properties may not appear in council scheduling systems. If your address has no fixed collection day, the app will say so — it won't show incorrect dates.
• Some Aberdeenshire dates are estimated. Aberdeenshire's system publishes your next collection per bin together with its normal frequency (“3 weekly”). We extend that council-published frequency for a short, bounded period. A date worked out that way is never drawn in colour: its bin is shown as an outline rather than a filled one, and the day is labelled ESTIMATE — it follows the council's own pattern but has not been individually published, and can shift around bank holidays. The next collection shown is always the council's confirmed one. We only extend about eight weeks ahead, and we stop before Christmas and New Year entirely: festive collections move every year, so an estimate over that period would be a guess we have good reason to doubt. Check with the council directly for December and January.
• Aberdeen City dates are never estimated. Aberdeen City's system supplies actual scheduled collection dates months ahead, and the app shows those dates as received — there is no application-side projection for Aberdeen. The council's own public page may display fewer upcoming dates than its scheduling system returns; both come from the same source.
• Aberdeen City Council's, Aberdeenshire Council's, Scottish Borders Council's, Renfrewshire Council's, East Dunbartonshire Council's, Falkirk Council's, West Dunbartonshire Council's, North Ayrshire Council's, Highland Council's, Comhairle nan Eilean Siar's and Angus Council's systems will process your UPRN when we query them. Moray Council's, Clackmannanshire Council's, West Lothian Council's and Fife Council's systems each process their own opaque property reference the same way; Fife Council's then looks up the property's UPRN itself. Orkney Islands Council's system is queried by collection AREA, never by a property or address of yours at all. Stirling Council's and East Ayrshire Council's systems each process an id issued by their shared waste-calendar platform, never a UPRN. Each council's data handling is governed by its own privacy policy.
• If your postcode is newer than our built-in map, it is sent to postcodes.io and possibly findthatpostcode.uk to find out which council serves it. This does not happen for a postcode the map already holds, which is nearly all of them. Their handling follows their own privacy policies, linked above.
• Your ISP sees that you visited this site. That's true of every website.
• Vercel's infrastructure-level logging follows Vercel's own privacy policy, not ours.

Your rights

We do not run user accounts or keep a customer database, so there is normally no profile here for us to retrieve, correct, or delete. Data saved by the app in your browser can be removed by clearing site data, or by removing recent addresses in the app.

If you have a question about a particular record, how the site works, or a privacy concern, get in touch via the contact page. We will explain what we can access and, where infrastructure is controlled by a third party, point you to the relevant service's process.

Changes to this statement

If we add a new third-party service, change how caching works, or make any other privacy-relevant change, we will update this document and note the date at the top. We won't bury changes.