How to Make 恋みくじ Results Shareable Without Storing Personal Data

doichizen — Thu, 03 Sep 2026 05:33:20 +0000

This post explains one of the technical and privacy questions behind the project rather than presenting an independent review.

A share button seems like a small feature.

The visitor receives a result, presses “Share,” and sends it to a friend. From a product perspective, sharing can help an experience travel beyond its original website.

But when the product involves personal emotions, the architecture behind that button deserves more attention.

A 恋みくじ is a Japanese-style love fortune. Before drawing one, a visitor may be thinking about an unspoken feeling, a delayed reply, reconciliation, or uncertainty about a relationship.

The application does not need to know that private question.

More importantly, the shared URL should never expose it.

This creates an interesting engineering problem:

How can we make a personalized-looking result easy to save and share without storing the visitor’s identity, question, or relationship history?

Here is the privacy-first architecture I would use.

Begin with a data boundary

Before choosing a database or sharing library, define which information is allowed to leave the browser.

For a 恋みくじ application, the data can be divided into three categories.

Public content

This is content that already belongs to the application:

Fortune result ID
Published headline
Published interpretation
Interface language
Public artwork
Product URL

Private context

This exists only to help the visitor think about their situation:

The person’s name
The visitor’s romantic question
Relationship history
Message contents
Personal notes
Reasons for drawing the fortune

Operational data

This may be collected in a limited form to operate the service:

Page load count
Draw completion
Error information
Selected language
Performance measurements

The basic rule is simple:

A shareable result should be constructed from public content, not private context.

If the visitor selects “waiting for a reply,” the application may use that choice locally to select a suitable category of results. The shared page does not need to say who the visitor is waiting for or what message was sent.

The URL is not private storage

One of the easiest implementation mistakes is placing the entire interaction inside a query string.

text
example.com/result
?name=Alex
&question=WillTheyReply
&situation=Reconciliation
&result=GoodLuck

This URL can leak through:

Browser history
Server logs
Analytics systems
Screenshots
Referrer headers
Messaging applications
Link preview services

Removing the person’s name but leaving a detailed romantic question in the URL does not solve the problem.

A safer URL contains only a public result identifier:

text
example.com/fortune/en/gentle-patience-014

Here, gentle-patience-014 identifies a published result from the application’s public catalog.

It does not identify the visitor.

typescript
type PublicShareReference = {
resultId: string;
locale: string;
};

The route can use these two values to look up the correct public content.

typescript
async function loadSharedFortune(
resultId: string,
locale: string
) {
return fortuneRepository.findPublished({
id: resultId,
locale
});
}

If someone changes the ID manually, the worst outcome should be that they see another public fortune or a 404 page.

A result ID must not provide access to private records.

Do not confuse obscurity with privacy

A long random URL may look private:

text
example.com/r/7JkP2mQx9A

But an unguessable identifier does not automatically make the underlying system privacy-friendly.

If the token points to a database record containing a visitor’s name, question, device ID, and complete interaction history, the system is still storing personal data.

Opaque IDs are useful when a private server-side record is genuinely required. They should not be used to justify collecting information the feature does not need.

For a finite catalog of 恋みくじ results, a public result ID is often enough.

No visitor record is necessary.

Use a small share object

The browser only needs a title, short text, and public URL.

typescript
type ShareableFortune = {
title: string;
summary: string;
url: string;
};

It can be constructed from published content:

typescript
function createShareData(
result: FortuneResult,
locale: string
): ShareableFortune {
return {
title: ${result.headline} — 恋みくじ,
summary: result.shortInterpretation,
url: https://example.com/fortune/${locale}/${result.id}
};
}

Notice what is missing:

No account ID
No email address
No personal question
No relationship status
No session token
No analytics identifier

The result still feels personal because it appeared after an intentional interaction. It does not need to contain personal data to preserve that feeling.

Use the Web Share API as progressive enhancement

On compatible browsers, the Web Share API provides a native sharing interface.

typescript
async function shareFortune(
shareData: ShareableFortune
): Promise {
if (navigator.share) {
await navigator.share({
title: shareData.title,
text: shareData.summary,
url: shareData.url
});

return;

}

await navigator.clipboard.writeText(shareData.url);
showMessage("Link copied");
}

The feature should still work when navigator.share is unavailable.

A good fallback order is:

Open the native share sheet when supported.
Copy the public URL to the clipboard.
Display the URL if clipboard access fails.

typescript
async function copyShareUrl(url: string): Promise {
try {
await navigator.clipboard.writeText(url);
return true;
} catch {
return false;
}
}

Copying a link is not as visually impressive as opening a native menu, but reliability matters more than novelty.

The interface should also confirm what happened. A silent copy action leaves visitors unsure whether the button worked.

Social previews need server-visible metadata

A single-page application can update its title and description after JavaScript loads:

javascript
document.title = "A Gentle Turning Point — 恋みくじ";

That is helpful for the visitor, but many social preview crawlers do not run client-side JavaScript in the same way as a browser.

If the shared URL needs a specific preview image and description, those tags should appear in the initial HTML response.

html
property="og:title"
content="A Gentle Turning Point — 恋みくじ"
/>

property="og:description"
content="A small change in perspective may reveal a new path."
/>

property="og:image"
content="https://example.com/share/gentle-turning-point-014.png"
/>

property="og:url"
content="https://example.com/fortune/en/gentle-turning-point-014"
/>

name="twitter:card"
content="summary_large_image"
/>

There are two practical ways to generate this HTML.

Static generation

If the result catalog is finite, the application can create one static share route for every published result and language.

typescript
for (const result of publishedResults) {
for (const locale of supportedLocales) {
generateResultPage(result, locale);
}
}

Advantages include:

Fast delivery
Easy caching
No database query during sharing
Predictable metadata
Low operational complexity

Server rendering

A server handler can look up the result ID and render the metadata dynamically.

typescript
export async function renderSharePage(
resultId: string,
locale: string
) {
const result = await getPublishedResult(resultId, locale);

if (!result) {
return renderNotFound();
}

return renderHtml({
title: result.headline,
description: result.shortInterpretation,
image: result.shareImage
});
}

This is more flexible, but it introduces additional caching, validation, and availability concerns.

For a relatively stable result catalog, static generation is often the simpler choice.

Generate images from trusted content

Visual result cards are attractive because they can preserve the atmosphere of the experience when shared outside the website.

However, image generation can become a security problem if arbitrary user input is inserted into a template.

A safer renderer accepts only trusted catalog content:

typescript
type ShareCardInput = {
resultId: string;
locale: string;
};

The server retrieves the published text itself.

It should not accept a complete headline from the request:

typescript
// Avoid this design
type UnsafeShareCardInput = {
customHeadline: string;
customMessage: string;
};

Allowing arbitrary text can lead to impersonation, offensive content, layout abuse, resource exhaustion, or misleading cards carrying the product’s branding.

If custom text is not essential, do not support it.

The generated images can be cached using stable paths:

text
/share-cards/en/gentle-patience-014-v2.png

Including a content version makes cache invalidation explicit.

Saving is different from sharing

Some visitors may want to keep a result without publishing it anywhere.

The application can offer a local download:

typescript
async function downloadResultCard(
imageBlob: Blob,
filename: string
) {
const url = URL.createObjectURL(imageBlob);
const anchor = document.createElement("a");

anchor.href = url;
anchor.download = filename;
anchor.click();

URL.revokeObjectURL(url);
}

This gives the visitor control over where the file goes.

The application does not need to upload the image to a user account first. It also does not need access to the visitor’s photo library or cloud storage.

“Save” should mean exactly what the interface claims. It should not silently create a public page.

Avoid creating thousands of thin indexable pages

Share routes introduce an SEO question.

If every result has a public URL, it may be tempting to make every result page indexable. A large collection of pages containing only a headline and two short paragraphs, however, may provide little independent search value.

A better strategy is to separate shareability from indexability.

The main product page can explain:

What 恋みくじ means
How the experience works
Its cultural background
Privacy expectations
Frequently asked questions
The difference between entertainment and advice

Individual result routes can remain accessible for sharing without being treated as primary search landing pages.

For example:

html

This tells search engines that the page may be followed but should not be included as an individual search result.

Not every public URL needs to become an SEO page.

Indexing should be based on lasting value, not the number of routes an application can generate.

Keep analytics away from private meaning

A useful sharing event might look like this:

typescript
analytics.track("fortune_share_started", {
locale: currentLocale,
method: "web_share"
});

Before attaching more information, ask why it is necessary.

Does the analytics platform need the exact result ID?

Does it need the situation selected before the draw?

Does it need a persistent identifier connecting this draw to future visits?

In many cases, aggregate counts are sufficient:

Share button opened
Link successfully copied
Download completed
Share operation cancelled
Error occurred

If the product needs result-level statistics, the result ID is public catalog information. Even then, it should not be connected to personal questions or persistent visitor profiles without a clear reason and appropriate consent.

Handle cancellation as a normal outcome

Sharing is user-controlled. Closing the native share sheet is not an application error.

typescript
async function handleShare(
shareData: ShareableFortune
) {
try {
await navigator.share(shareData);
} catch (error) {
if (error instanceof DOMException &&
error.name === "AbortError") {
return;
}

reportTechnicalError(error);

}
}

Do not show an alarming message when the visitor simply decides not to share.

The application should also avoid immediately asking again. A cancelled share action should end quietly.

Accessibility remains part of sharing

A visual card should not be the only representation of the result.

The shared page needs real text so that it can be:

Read by screen readers
Translated
Copied
Enlarged
Displayed when the image fails
Understood without relying on color

Share and copy buttons need descriptive labels:

html

Share result

Status messages should be announced without moving focus unexpectedly:

html

Link copied

A beautiful image is an enhancement. It should not become the only accessible source of information.

Applying the idea to a real project

I have been considering these decisions while working with Ichizenn’s 恋みくじ, a browser-based Japanese love-fortune experience.

The key architectural lesson is that personalization does not always require identification.

A result can feel relevant because of timing, context, writing, and interaction design. The application does not need to know who the visitor is or store the private thought that brought them there.

This changes the sharing model completely.

Instead of sharing a user record, the application shares a reference to published content.

The resulting architecture

The complete flow can remain relatively small:

The visitor privately considers a romantic question.
The browser selects a suitable published result.
The application displays that result without requiring an account.
The share object contains only a public result ID and locale.
The public route renders server-visible metadata.
The visitor chooses whether to share, copy, download, or leave.
No personal question is included in the shared artifact.

The system can still provide:

Native mobile sharing
Attractive social previews
Downloadable result cards
Multiple languages
Stable public links
Basic aggregate analytics

It does not need a profile database to accomplish any of these things.

Final thoughts

Privacy-friendly architecture is often described as a limitation.

In this case, it can make the product simpler.

By refusing to store information that the sharing feature does not need, we reduce:

Database complexity
Access-control requirements
Potential data leaks
Account recovery flows
Moderation problems
User anxiety about personal questions

The most important design rule is also the simplest:

Share the fortune, not the person behind it.

For products involving emotions, reflection, health, identity, or personal decisions, what information could remain entirely inside the visitor’s browser?

DEV Community: doichizen

How to Make 恋みくじ Results Shareable Without Storing Personal Data