Designing Effective Campaigns

Chapter 4 walks you through where to click in the campaign wizard. This guide covers what to put there — how to design a simulation that behaves like a real attack, personalizes correctly, tracks every interaction, and ends in a teachable moment. It assumes you’ve read Campaigns and focuses on the design decisions inside each step.

A campaign in PhishSpot has five moving parts, and good design means making them consistent with one another:

1. Sender identity — the name and address the email appears to come from.
2. The email — subject and HTML body, personalized per recipient.
3. The landing page — what the recipient sees after they click (optional).
4. The end action — the “teachable moment” after a click or form submit.
5. The recipients — who receives it, and how the message is tailored to them.

The rest of this chapter takes each in turn, with emphasis on the platform mechanics — the merge tags and tracking keys — that the manual hasn’t documented in depth before.

30.1 Personalization with merge tags (the “keys”)

Merge tags are the {{placeholders}} you drop into your content that PhishSpot replaces with each recipient’s real data at send time. They are the single most effective lever you have: a message addressed to “Jan” from “your IT team at [your company]” is dramatically more convincing than a generic blast.

Syntax. Wrap the tag name in double curly braces: {{first_name}}. Tags are case-insensitive and tolerate surrounding spaces — {{First_Name}} and {{ first_name }} both work. A tag PhishSpot doesn’t recognize is left in the message literally, so a typo like {{frist_name}} will ship as visible text. Always send a test (see §30.6) to catch these.

The available tags differ between the email and the landing page, because each is rendered in a different context. Use only the tags valid for where you’re writing — the editor validates this and won’t let you save an email that references a landing-only tag.

Email subject & body — available tags:

Tag	Replaced with	Example
{{first_name}}	Recipient’s first name	Jan
{{last_name}}	Recipient’s last name	Kowalski
{{full_name}}	First + last name	Jan Kowalski
{{email}}	Recipient’s email address	jan.kowalski@firma.pl
{{position}}	Recipient’s job position	Senior Analyst
{{department}}	Recipient’s department	Finance
{{company}}	Your account name	Acme Sp. z o.o.
{{campaign_name}}	The campaign’s name	Q2 Invoice Test
{{landing_url}}	The recipient’s tracked link	https://officelogin.in/l/ab12cd34?d=…

Landing page & awareness message — available tags:

Tag	Replaced with
{{first_name}}, {{last_name}}, {{full_name}}, {{email}}	As above
{{company}}	Your account name
{{landing_url}}	The recipient’s tracked link
{{elearning_url}}	The recipient’s training link (used on the awareness page)

Note

{{landing_url}} is the tracked phishing link — there is no {{phishing_url}} tag. {{company}} resolves to your account name (the organization running the simulation), which is what makes “a message from your own company” pretexts work. For the full reference, see Template Variables.

Design tips:

• Personalize the subject, not just the body — Jan, akcja wymagana na Twoim koncie lifts open rates more than a generic subject.
• Put {{landing_url}} behind a real-looking button or link, never as raw text. Recipients rarely click a visible URL.
• Use {{department}} / {{position}} to make a pretext role-appropriate (an invoice for Finance, a benefits notice for HR). See Social Engineering & Persuasion for targeting strategy.
• Leave a tag out rather than risk it being empty — an awkward “Dear ,” (no first name) is a giveaway. Empty values render as blank, so confirm your contact data is complete for the fields you rely on.

30.2 How tracking works, and why it shapes your design

PhishSpot records each recipient’s journey through the campaign funnel — Sent → Delivered → Opened → Clicked → Submitted → Trained. Understanding how each stage is detected helps you design content that measures what you actually care about.

• Opened is detected by an invisible 1×1 tracking pixel embedded automatically in every email. The recipient’s mail client loads it when the message is displayed. Because many clients (notably Apple Mail Privacy Protection and some corporate gateways) block or pre-fetch remote images, treat the open rate as a soft signal — don’t design a campaign whose success depends on open tracking alone.

• Clicked is detected when the recipient visits their personalized link. That link carries an opaque per-recipient key — the deliverable ID — as the d query parameter:

  https://<your-landing-domain>/l/<random-path>?d=<deliverable-id>

  This is the value behind {{landing_url}}. The key identifies exactly one (campaign, recipient) pair, which is how PhishSpot attributes a click to a specific person without putting their email address in the URL. Never hand-edit or hard-code a link in your email — always insert {{landing_url}} so the per-recipient key is preserved. A static URL would attribute every click to nobody.

• Submitted is detected when the recipient submits a form on your landing page (§30.3). Every field they type is captured, except routing and security fields — so you measure not just that someone submitted, but what they were willing to give up.

Tracking-only campaigns. If you only want to measure who clicks — without hosting a fake login — you can disable the landing page (Step 3). The link still records the click via its key, then immediately runs the end action (e.g. straight to an awareness page). This is the lightest-touch design and avoids capturing any credentials at all.

30.3 Designing the landing page

When enabled, the landing page is the destination of {{landing_url}}. It’s plain HTML you control, hosted on your selected platform domain. Common patterns:

• Login clone — a copy of a Microsoft 365, Google, or internal portal sign-in screen. The classic credential-harvest test.
• File-share / document — “a document was shared with you, sign in to view.”
• Notification / action page — “confirm your details,” “review this policy.”

Forms. You don’t need to wire up a form action — PhishSpot rewrites any <form> on the page to post back to the tracking URL automatically. Whatever fields you include (username, password, etc.) are captured into the recipient’s event record on submit, minus internal routing/security fields. Design the form to mirror whatever you’re imitating.

You can use the landing-context merge tags (§30.1) here too — e.g. pre-filling {{email}} in a username field is a strong realism touch.

Caution

Decide deliberately whether to capture passwords. Capturing the fact of submission is usually enough to drive training, and storing real passwords — even briefly, even your own employees’ — raises the stakes of the exercise. Many programs capture submission without retaining the password value. Align this with your security and HR policies.

For the technical side of making the page (and especially the email) render correctly, see Email Client Compatibility.

30.4 The teachable moment (end action)

What happens after a recipient clicks or submits is where the simulation turns into training. PhishSpot offers four end actions (Step 4):

End action	Behavior	Use when
Nothing	Blank page	You only need the click/submit recorded; minimal disruption
Redirect to course	Sends the recipient to an assigned e-learning course	You want immediate, in-context training — the strongest learning moment
Awareness message page	Shows a custom “this was a simulation” page (HTML you write, supports merge tags)	You want a branded, reassuring explainer without a full course
Redirect to URL	Sends them to any external URL	You want them to land on, e.g., the real portal or an internal policy page

The most effective design is redirect to course: the recipient is most receptive in the seconds after they realize they fell for it. Pair the campaign with a short, relevant course — see Courses.

On the awareness page you can use {{first_name}} to address the recipient and {{elearning_url}} to offer an optional follow-up lesson. Keep the tone non-punitive (more on this in Social Engineering & Persuasion §32.7).

30.5 Sender identity & deliverability

The most carefully crafted email is worthless if it lands in spam. Two fields define the sender (Step 1):

• Display name (from_name) — what appears as the sender, e.g. IT Security.
• From email (from_email) — the address, which must be on the platform domain you select for the campaign.

A few realities to design around:

• The sending domain must be active and not blocked to launch. Pick a domain whose name supports your pretext — officelogin.in reads very differently from random-string.xyz. See Domains for provisioning and BYOD setup.
• Deliverability depends on the domain’s SPF/DKIM/DMARC and reputation, configured during domain setup. A brand-new domain with no warm-up may go to spam regardless of content.
• If your test lands in spam, consult Spam Filter Whitelist — you may need recipients’ mail admin to allow the simulation source.

Match the display name and domain to the pretext: a “Microsoft” email from acme-internal.com is incoherent and trains recipients on the wrong signal.

30.6 Test and verify before launch

Never launch a campaign you haven’t seen rendered. Before Step 6:

1. Send a test email to yourself (Campaign Actions → Send Test Email). Confirm: merge tags resolved (no stray {{…}}), the link works and lands on the right page, images load, and formatting holds.
2. Check both desktop and mobile. After launch, the per-recipient preview in Reports & Analytics §11.5 shows the exact email each person received with a desktop/mobile toggle — use it to verify rendering and personalization.
3. Walk the full path — click your own test link, submit the form, and confirm the end action fires (course, awareness page, or redirect) as intended.

A quick pre-launch checklist:

• Subject and body personalize correctly (test email received and read)
• {{landing_url}} is behind a button/link, click is tracked
• Landing page renders; form posts; submission recorded
• End action fires and points to the right course/page/URL
• Sender domain is active; test didn’t land in spam
• Email renders cleanly on desktop and mobile

---

See also: Campaigns · Template Variables · Email Client Compatibility · Social Engineering & Persuasion · Domains · Reports & Analytics