Changes to Campaign Custom Code: March, 2026

We’re rolling out an update to the underlying architecture of Tradable Bits engagement campaigns that improves backend consistency and helps support future development across the platform.

For most engagement campaigns, no action is needed. However, campaigns that rely on custom CSS, JavaScript or HTML may be affected.

Who may be affected

Your engagement campaigns may need review if they use custom code to:

• Style form fields or inputs using specific classes or IDs
• Auto-check checkboxes through custom JavaScript
• Auto-fill inputs based on URL parameters without using our native simple_session_init
• Override native form submission behaviour
• Replace or override default labels or placeholders through custom code

If you don’t tend to use custom code on your engagement campaigns or business settings, this update should have no impact.

What’s changing

We are standardizing engagement campaign naming conventions across the platform. As part of that work, some classes and IDs used in engagement campaigns are changing.

If your custom code references older names, styling or functionality may break until that code is updated.

High-impact class changes

• entry-form-section-field → form-field
• field-phone → phone-input-wrapper
• birth-date-field-group → date-input-wrapper

High-impact ID changes

• first_name → first-name
• last_name → last-name
• age_day → birth-date-day
• age_month → birth-date-month
• age_year → birth-date-year
• is_subscribed → is-subscribed
• Is_phone_subscribed → is-phone-subscribed

High-impact custom field updates

Campaigns using custom fields may also need review if custom CSS or JavaScript references those fields by their HTML class selectors . The custom field names themselves are not changing, and forms will continue to function normally.

However, the underlying selectors used to identify those fields in custom codes are changing under the new architecture. For example, .custom_field would now become .form-field[data-field-name="custom_field"].

If you use custom code to style, show, hide or otherwise interact with custom fields, we recommend reviewing those references as part of this update. In particular, if you have embedded ticket interest forms, please reach out.

What we are doing to mitigate impact

Our solutions engineering team is patching existing campaigns for all of the above-identified values to update them to the new class names. However, we still recommend a quick check-in on high-priority campaigns where custom code is used to ensure they aren’t impacted if they’re going live.

What to keep an eye out for on campaigns using custom code:

Depending on how your campaign was built, you may notice:

• Styling changes on form fields
• Broken input behaviour
• Checkboxes not auto-selecting as expected
• URL-based field population no longer working
• Form submissions failing if native JavaScript has been overwritten

The fastest way to restore form functionality

If a campaign form breaks after this update, the fastest way to restore native functionality is often to disable any conflicting custom JavaScript. This removes custom script interference and allows the updated native architecture to take over.

What we recommend:

1. Review any custom CSS, JavaScript, or HTML tied to form fields
2. Check for references to the older class and ID names listed above
3. Let us know about any high-priority live campaigns using custom code
4. If an engagement campaign form stops working after the update, disable JS first, then review the custom in question

Need help?

If you believe one of your engagement campaigns may be affected, you can reach out to support@tradablebits.com and include:

• The campaign ID and name
• Whether the campaign is currently live
• Whether it uses custom CSS, JS or HTML
• A short description of what appears broken

We’re actively monitoring impacted campaigns and can help your team review and adapt custom code where needed.