Solving the Alt Problem: How We Automated Secondary Accounts Without Breaking the Leaderboard
What you will learn in this article:
Use Multiple Accounts Freely: You can now bring any secondary account to guild events, and all your earned Guild Points will automatically credit directly to your primary account.
Keep Competition Fair: Daily point caps (300 GP) remain linked to you as a single player, keeping leaderboards competitive and preventing ghost accounts from taking prize slots.
Zero Work for Leads: Our logging system handles the mapping invisibly behind the scenes—no manual name swaps or extra admin required. IMPORTANT: If you regularly run on a secondary account and want it linked to your primary profile for GP tracking, reach out to Matt or any of the Stewards with your alt handle. Every active guild eventually runs into the "alt dilemma."
Members who have been with you for years naturally branch out. They build a second account to try a different class from scratch, store extra gear, replay alliance questlines, or simply help fill a trial roster when a group is short on tanks or healers. In an active, social guild, this flexibility is invaluable—nobody wants an event cancelled because one person is missing.
However, once you introduce a competitive community layer like Guild Points (GP), monthly leaderboards, and prize rewards, that flexibility creates an administrative headache.
The Problem: When Playstyle Meets Competition
Our event tracking relies on an automated pipeline: raid leads run events, log attendee handles via our custom in-game addon, and paste the run details into our central Google Sheets engine. From there, points accumulate, daily caps apply, and leaderboards update in real time.
When members participate on secondary accounts, two issues immediately arise:
Leaderboard Splitting: If an alt account earns points under its own handle, it creates a "ghost" competitor. A single member could inadvertently occupy multiple spots in the monthly Top 10, crowding out other players and claiming duplicate prizes.
Cap Circumvention: Daily caps exist to ensure members can stay competitive without burning out. Two separate accounts belonging to the same human could double the daily limit if left unmonitored.
The obvious manual fix—asking event leads to memorise every member’s alternate handles and edit names manually before logging—was a non-starter. Raid leads volunteer their time to coordinate runs, call mechanics, and guide groups; the last thing they need is administrative paperwork at the end of a long trial.
We needed a solution rooted in a foundational principle: One Human = One Account.
Crucially, it had to happen without manual friction for event leads or feeling like a penalty for members who play on alts.
The Architecture: Invisible Backend Aliasing
Rather than policing rosters by hand, we built an automated alias mapping layer directly into our spreadsheet architecture.
Here is how the system fits together behind the scenes:
[ In-Game Addon Roster Scraping ]
│
▼
[ Reporting Sheet (A6:A17) ]
│
▼
[ updateColumnD() Hook ]
│
├─► Scans & Cross-References 'Alts' Master Table
├─► Swaps Alt Handles to Registered Main Accounts in-place
└─► Synchronises Logger Cell (A19)
│
▼
[ Formula Validation & Point Processing ]
│
├─► Enforces Single 300 GP Daily Cap
├─► Directs 100% of Points to Main Account Profile
└─► Keeps Leaderboard Clean & Fair
1. The Dynamic Aliasing Layer (When you log an event)
Whenever an event lead hits the button to log a report, our script executes an alias resolution step before validation checks or point formulas kick in.
It reads an internal Alts registry (Column A: Alt Handle, Column B: Primary Handle) and performs an in-memory, case-insensitive comparison across the attendee cells (A6:A17). If it finds an alt handle—such as @bob2—it immediately swaps the value in-place to the registered primary handle (@Bob1). It also checks the logger field (A19) to prevent false validation flags if a lead logs while playing an alt.
Because this substitution happens before the sheet calculates formulas, every dependent mechanism—daily cap enforcement, duplicate event prevention, and historical logging—sees only the primary account.
2. The Defensive Gatekeeper (registerNewPlayers)
Our sheet features a self-service registry tool: if an attendee's name isn't found in the master database, leads can click a button to register them on the fly.
To prevent alts from being mistakenly registered as new members, we updated the registration script to cross-reference the Alts sheet first. If a lead attempts to register an alt, the script intercepts the operation, keeps the master member list clean, and displays an informative pop-up:
"This player is a recognized secondary account. No registration needed—points will map automatically upon logging."
3. Mathematical Verification via Modern Arrays
Before rolling out the system, we needed to verify whether historical daily caps had ever been breached across alt/main combinations.
Rather than relying on clunky helper columns or external scripts, we leveraged Google Sheets' modern array engine (LET, MAP, BYROW, and LAMBDA) to build an in-memory audit pipeline. The formula dynamically parsed timestamps, matrix-checked the 12-player roster columns across thousands of historical log rows, grouped runs by discrete calendar dates, and verified whether any member had ever exceeded the 300 GP daily cap across both handles combined.
The audit proved the historical records were completely clean—confirming that our players were competing fairly all along, and that this update was purely about streamlining the technical future.
What This Means for the Guild
This update strikes the balance we aim for in all our guild systems:
For Event Leads: Zero extra steps. Grab the group, run the content, paste the addon output, and hit log. The sheet does the rest.
For Alt Players: You can switch characters freely to help the guild or play how you like, confident that your effort counts toward your monthly progression.
For the Community: Leaderboards remain fair, authentic, and representative of individual community members.
Good guild management isn't about imposing more rules—it is about designing systems that quietly remove friction so everyone can focus on playing the game together. Updates to rule 3A reflect the above changes
Comments