How pre-filling works in practice
The principle is simple. The alumni platform already knows a lot about the alumnus it is reaching out to: last name, first name, class, major, academic track, sometimes the situation declared at the last profile update. Rather than asking the alumnus to retype this information, you push it into the form at load time.
Technically, two mechanisms coexist. The first is the parameterized URL: the link sent to the alumnus contains a unique identifier (token) that the platform uses to fetch the profile and pre-load the fields. That's what Google Forms does when used seriously, but only on condition that you manually generate the links and parameters for each alumnus — which isn't sustainable beyond 50 profiles.
The second is authentication: the alumnus logs into their space and the form opens already filled with the profile data. More robust, more GDPR-friendly, but it requires the alumnus to have an active account. On modern alumni platforms like Terrilink Surveys, both mechanisms live side by side: signed token by default, optional authentication for alumni who want more control.
The result: the alumnus clicks the link from their email or SMS, the form opens, their name is already there, their class too, their major too. They confirm or correct, complete the truly new questions, and click "submit". Total time: 2 to 3 minutes instead of 8 to 12.
Pre-fillable data vs data to collect
Not all data can be pre-filled. Three families to distinguish.
Structural data (always pre-fillable): last name, first name, graduation class, degree type, major, dual degree, honors. This data doesn't change — it can be pre-filled read-only, the alumnus doesn't even have to confirm it.
Older declarative data (pre-fillable with confirmation): current position, employer, city, status. This data changes over time. You pre-fill it with the last known value and explicitly ask the alumnus to "confirm or update". The classic mistake: pre-filling without asking for confirmation, and ending up with stale data — see the next section.
New data (never pre-fillable): current salary, satisfaction with the program, opinion of the employer, career plans 2-3 years out. This data is the very point of the campaign. It must be collected fresh in every wave, with no assumption.
On a typical CGE 6-month survey, we observe that 40 to 50% of the fields are pre-fillable (categories 1 and 2), 50 to 60% must be collected fresh. That ratio is what takes the form from 10 minutes to 3 minutes — not a brutal removal of questions.
Measured impact: average response time, completion rate
On the campaigns we track, here are the orders of magnitude observed at steady state.
- Average completion time: drops from 9-12 minutes (without pre-filling) to 2-3 minutes (with pre-filling of categories 1 and 2).
- Mid-form abandonment rate: drops from 25-30% to 5-10%. Mid-form abandonments are overwhelmingly tied to perceived friction, not content.
- Overall class completion rate: rises from 40-50% to 60-70%. That's the net effect, all else being equal.
- Data quality: an alumnus who retypes their name has a 1 to 2% risk of a typo. Pre-filling eliminates this source of error, which matters for cross-referencing with other databases (CCN, INSEE).
For a class of 400 alumni, going from a 45% to a 65% response rate means 80 additional responses. On the CGE report, those 80 responses make the difference between a solid case and one that barely passes. For comparisons by school type, see our article on CGE survey response rates by school type.
The risk of pre-filling too much: alumni who confirm without checking
Pre-filling has a well-known perverse effect: the alumnus confirms without checking. If the form already shows "Current position: Consultant at X (updated in 2024)" and the alumnus changed jobs 4 months ago, they are tempted to click "Confirm" without correcting.
The result: stale data that gets frozen into the CGE report. It's the schools that pre-fill aggressively, with no explicit prompt to update, that see their median salaries stagnate year over year (old salaries renew passively) or their permanent-contract rates artificially inflate.
Three concrete precautions. First, visually flag the pre-filled fields ("Based on our records...") with a "Confirm or edit" button. The alumnus has to click actively, not just let it slide. Second, ask an explicit question about freshness: "Is this information up to date? Yes / No, I'm updating it". Third, always collect certain data fresh: current salary, satisfaction. No pre-filling on those, whatever the friction savings.
The outcome: a form that drops to 3 minutes for "stable" alumni and 4-5 minutes for those whose situation has changed, but with data freshness preserved.
GDPR: which legal bases for pre-filling?
Pre-filling personal data into a form the alumnus did not explicitly initiate is processing data. So a legal basis is mandatory.
For a CGE survey, two legal bases coexist in practice. The "legal obligation or public-interest task" basis is invoked by certain public schools for the HCERES / CGE report — producing placement statistics being an obligation tied to accreditation. The "legitimate interest" basis is used by private schools: tracking graduate placement is a legitimate interest of the institution, provided the alumnus can object.
Consent (GDPR Article 6.1.a) is generally not the right basis, because it requires obtaining active consent before pre-filling, which cancels the "friction saving" effect.
Whatever the basis, three requirements to respect. First, clear information: the alumnus must know, before the form, that their personal data is already known to the school and will be used for pre-filling. Second, the right to object mentioned explicitly in the form and in the privacy policy dedicated to the campaign. Third, minimization: pre-fill only what is strictly useful — not the social security number, not the full date of birth if the class year is enough.
To frame this with the school's DPO, see our GDPR alumni platform guide.
Implementation: what a CGE survey software needs to do it
To pre-fill cleanly, the software needs to know how to do three things. First, receive an alumni database via CSV or API, with a stable identifier per alumnus. Then, generate unique signed links (typically JWTs or time-limited tokens), so that a link sent to one alumnus cannot be reused by someone else. Finally, pre-load the fields from the profile and make them editable or read-only depending on the data category.
On the Terrilink side, these three functions are native on the CGE / CTI surveys page. The alumni database lives in the SaaS all year round, fed by mentorship programs, events, and membership dues. At CGE campaign time, it feeds the pre-filling automatically, with no export-import at all. The fastest way to get started is to book a demo.