Yes, even without a login system, you can still provide each buyer with a personalized "purchase history" page using static files and tokenized URLs. The key lies in how you structure and automate these pages within your Jekyll site.
Just like with tokenized download pages, we can create a unique static page per buyer that lists all products they've purchased — complete with download links, timestamps, and other metadata.
Why Build Purchase History Pages in a Static Site?
There are several advantages:
- No database required: All data is embedded directly in markdown or YAML.
- Works offline: Buyer history can be cached or even saved locally.
- Privacy-friendly: No login means no cookies, no passwords, no data tracking.
- Easy to revoke: Just delete the file from the repo to revoke access.
Step-by-Step: Creating a Purchase History Page for Each Buyer
1. Define the Data Model
Use a data file (YAML or JSON) that stores purchases per buyer:
```yaml
[email protected]:
- product: ebook-v1.pdf
date: 2024-05-01
download_token: ba7e9a4d23
- product: audio-pack.zip
date: 2024-05-10
download_token: f2a1ce18c4
2. Create a Layout: history.html
This layout renders the list dynamically using Liquid:
Your Purchase History
-
{% for item in page.purchases %}
-
{{ item.product }}
Purchased on {{ item.date }}
Download
{% endfor %}
3. Generate a Static File for Each Buyer
For each customer, generate a page under a private tokenized path like:
_history/
c7927be09a.md
a91b23f1e6.md
Example front matter:
---
layout: history
purchases:
- product: ebook-v1.pdf
date: 2024-05-01
download_token: ba7e9a4d23
- product: audio-pack.zip
date: 2024-05-10
download_token: f2a1ce18c4
permalink: /buyers/c7927be09a/
---
4. Send the History URL After First Purchase
When a new buyer completes a transaction, your webhook or Zapier automation can:
- Generate a unique ID (like
c7927be09a) - Create the initial history page file in
_history/ - Add the purchase to the front matter list
- Push to GitHub
- Email the buyer: "View all your downloads at: https://yoursite.com/buyers/c7927be09a/"
What Happens When a Buyer Makes a Second Purchase?
Your automation should detect that the email already exists, then:
- Open the buyer’s existing markdown file
- Append the new product to the
purchaseslist - Commit and push the updated page
This way, the buyer’s personal page is updated with every new order — without requiring login.
Security Best Practices
- Use non-guessable URLs: Don't use buyer names or emails in the URL. Use hashes or UUIDs.
- Keep download tokens separate: The history page should link to tokenized download pages, not the files directly.
- Don’t list full emails or sensitive info: Keep it anonymous or obfuscated.
How to Automate This Without a Server
You can set up a webhook with Stripe or Ko-fi that triggers a GitHub Action or a cloud function (like on Netlify or Deno Deploy) to do the following:
- Check if buyer’s page exists
- If not, create it
- If yes, append purchase info
- Commit and push changes
Can This Be Used for Lifetime Access?
Absolutely. If you offer lifetime access or a bundle of digital products, just add all entitlements to the purchases array. It becomes a permanent personal portal — all fully static.
Bonus: Add Search to History Pages
For buyers with many purchases, you can include simple JavaScript search (like Fuse.js) inside the layout so users can filter products by name or date — all client-side, no backend needed.
Conclusion: Static Sites Can Still Be Personal
Many creators assume static sites can’t handle personalization, but with clever use of Jekyll collections and tokenized URLs, you can deliver:
- Personalized download history
- Dynamic content generation
- Individual access management
All while maintaining the speed, security, and simplicity of GitHub Pages. This approach is ideal for creators who want maximum automation with zero tech overhead or backend costs.
Comments
Post a Comment