Registration Configurator
Your registration form, your rules — on your site, in the portal and in the app.
Design your event registration form yourself, drop it into your site with a single tag and keep it short with questions that appear based on earlier answers. See which form brings how many registrations; the same structure opens as the registration page in the mobile app.
Overview
Decide the fields, steps and rules yourself, embed the form on your own site and see which form brings how many registrations. No developer queue, no separate form tool.
With the Registration Configurator on the event edit screen you build the registration form for every event yourself: you decide which fields are visible, which are required or optional, in what order and over how many steps questions are asked. You work on a draft, try it in preview and publish when ready; the live form is never disrupted while you edit.
For multi-select questions such as business area, product/service or company type you can set rules like “at least 2, at most 3 selections”; the form shows the count and blocks submission when the minimum is not met. Email and mandatory agreement consents are always kept.
Business outcomes
- Marketing: a separate form per campaign, per-form registration and conversion view.
- Operations: required fields and selection counts are in your hands; no chasing missing data.
- IT / digital: single-tag embedding, server-side validation, registration-only key, allowed-sites list.
- Legal / data protection: “I have read” acknowledgements are recorded; a mandatory agreement consent cannot be made conditional.
Key capabilities
You design the form
Set the fields, order and steps; make each field hidden, optional or required. Add “at least / at most” rules on multi-select questions, and prepare labels, welcome content and documents in TR, EN and FR.
One tag, on your own site
You place the form on your site with a single tag (<qement-register>). The form runs in its own space, so your site’s styles do not break it; the height adjusts automatically and campaign source (UTM) information is passed into the form. When a registration completes, the form notifies your page. You decide which sites may show the form with an allowed-sites list; on a site that is not on the list the form is not displayed and a neutral message appears instead.
Ask the right question to the right person
Show a field depending on the answer to another question: if “Company type: Manufacturer” is selected, “Production capacity” is asked; other visitors never see it. A field whose condition is not met is not asked even if it is marked required, and it is not stored.
See which form brings how many registrations
Open a separate form per campaign: its own address, date and capacity; when capacity is reached or the period ends, the form says registrations are closed. For each form you follow views, registrations and conversion rate over 7 / 30 / 90 days. Measurement stores no personal data and is approximate.
Same rules on web, portal and mobile
When you enable it for an event, the mobile app shows “Register”; the form opens with the same fields, order and selection rules, and after a new registration the visitor is signed in directly. The registration window in the visitor portal also applies the same required, condition and selection-count rules for new registrations.
A confirmation email in your own words
Prepare the post-registration email per form, with separate subject and body for TR / EN / FR; placeholders let you add details such as the visitor’s name. The e-badge and calendar attachment are sent by email; for a language you leave empty, the event’s standard template is sent.
Security and data protection
Rules in the form are enforced on the server, not only on screen; CAPTCHA, a hidden honeypot field and rate limiting add layers against bots and abuse, and on the web form you can optionally require an email verification code. Which file, which form version, which channel and when an “I have read” acknowledgement was given is stored on the server as evidence; this supports your data-protection process.
Use cases
Scenarios drawn from real operational problems.
01Registration on our own site
- Problem
- A registration page needs a developer, a separate form tool or a static page; brand and domain get scattered.
- Solution
- Build the form in the configurator and place it with a single tag (
<qement-register>); styles do not clash and your page is notified when a registration completes. - Benefit
- Visitors register without leaving your site; campaign and redirect logic stays with you.
02The right question for the right person
- Problem
- Long forms that ask everyone the same questions get abandoned.
- Solution
- Tie fields to an answer (e.g. “Company type: Manufacturer” triggers “Production capacity”); a field whose condition is not met is not asked and not stored.
- Benefit
- A short, relevant form; operations collect only the data they need.
03Which form is working?
- Problem
- It is unclear which campaign and which registration page actually brought visitors.
- Solution
- Open a separate form per campaign; follow per-form views, registrations and conversion rate over 7 / 30 / 90 days and filter the registration list by form.
- Benefit
- A data-based starting point for moving budget to the channel that works (measurement is approximate).
04Same rules on web, portal and mobile
- Problem
- Building a separate form for every channel means inconsistent data and double work.
- Solution
- The same configuration applies to the embedded form on your site and to the “Register” page in the mobile app; the visitor portal’s registration window applies the same rules for new registrations.
- Benefit
- Consistent registration data, managed in one place.
05Confirmation email in your voice and language
- Problem
- The standard confirmation email does not match your brand voice or the visitor’s language.
- Solution
- Write per-form subject and body in TR / EN / FR, personalise with placeholders; the e-badge and calendar attachment stay. For a language you leave empty, the standard template is sent.
- Benefit
- Visitors are welcomed in your brand’s voice and their own language from the first moment.
06Security and data protection
- Problem
- Fake or faulty registrations pollute the list; showing that participation terms were read is hard.
- Solution
- Rules are enforced on the server; CAPTCHA, a hidden honeypot field, rate limiting and an optional email verification code add layers against bots and abuse; mobile new registrations always require a verification code. The “I have read” acknowledgement is stored with file, form version, channel and time.
- Benefit
- A cleaner registration list and records that support your data-protection process.
Frequently asked questions
How do we embed the form on our own site?
Place the single tag (<qement-register>) from the configurator’s Embed tab on your page; the container-snippet and direct iframe methods are also available. You decide which sites may show the form with an allowed-sites list; on a site not on the list the form is not displayed and a neutral message appears instead. The single-tag method requires the new loader version; sites using the old loader file keep working but do not recognise the tag.
Is the embed key safe? Is it not visible in the page source?
The embed key is visible in the page source; this is by design. The key is registration-only; registration rules and protections are enforced on the server. It is therefore not designed on the assumption that the key stays secret.
How complex can conditional fields be?
Conditions are single-level: a field can appear based on another answer, but a conditional field cannot itself be the source of another condition. The source can only be a choice field, the “member of a buying committee” question or country. Email, mandatory agreement consent and communication permissions cannot be made conditional. For events that use conditional fields, mobile users need to update the app.
How exact are the conversion and view numbers?
Measurement is approximate. A view is counted once per browser session, and at most once every five minutes per form from the same IP; behind a shared IP such as an office or mobile-carrier network, views can be under-counted and the conversion rate can read high. Days follow UTC. Counting starts on the day the feature is enabled, with no historical data; previews and displays blocked on a non-allowed site are not counted. The mobile app does not report views, so the rate may not show for the mobile form. Measurement stores no personal data.
Is there paid registration, file upload or updating an existing registration through the form?
No. Paid registration and file upload are outside the scope of this feature, and updating an existing registration through the form is not available. No promises are made on these.
What protects against fake registrations and bots?
Rules in the form are also enforced on the server; CAPTCHA, a hidden honeypot field and rate limiting work as layers. On the web form you can enable an optional email verification code; in the mobile app a verification code is always required for new registrations and cannot be turned off. No single layer gives absolute assurance; these layers are meant to make abuse harder.
What is the “official app only” option?
An optional check for the mobile app that accepts registrations only from the official store app. It is off by default; enabling it requires the new app version to be live in the store plus additional setup, and once enabled, users who have not updated the app cannot register. That is why we plan the decision to enable it together.
How is the “I have read” acknowledgement stored?
For a new registration, the acknowledged document, form version, channel and timestamp are stored on the server as evidence; agreement consents are kept with a copy of the content. This is a record that supports your data-protection process; it is not a legal guarantee or a statement of legal validity. The evidence is not written when the registration already exists or when an existing registration is edited; for older mobile versions that have not been updated, the evidence is not guaranteed.
How do I prepare a custom confirmation email? Where does the e-badge appear?
You write subject and body per form for TR / EN / FR; the body is entered as HTML source (there is no visual editor or on-screen preview), and scripts and similar content are stripped. Only defined placeholders can be used. Changes take effect when the form is republished; if there is no text for a language, the event’s standard template is sent. The e-badge and calendar attachment are sent by email; the web success screen does not display an e-badge. On mobile it is reached from the E-Badge screen after sign-in.
Does the registration window in the visitor portal apply the same rules?
For new registrations, yes: required, condition, selection-count and “I have read” rules are the same. When an existing registration is edited, the previous fixed form and rules apply. The portal window has no B2B field group, Instagram, language or participant-type fields, and no HTML content blocks.
Related modules
Explore other modules that work alongside this one in the same operational area and amplify the value of QEMENT.
Let’s set up your registration form together.
We will configure a registration form that fits your event in a live demo.