We’re trying a slightly different format for our release notes going forward. Instead of simply listing all the changes included in each release cycle, we’re going to try to make the release notes a little more human-readable and, we hope, understandable. In each release notes post, we’ll describe the most important changes, new features, or bugfixes and let you know what you might want to pay attention to as a result of these changes.
Without further ado, this week’s changes:
Rearchitecting Newspack Campaigns
Important note: This is a breaking change. If you have custom CSS to style prompts on your site, you may need to modify the CSS selectors, as prompt markup has changed.
This week’s releases include major under-the-hood changes to the Newspack Campaigns plugin. These changes fully deprecate AMP-related code in the plugin and move all reader segmentation logic and data to each reader’s own browser instead of handling on the site server. This should result in significant performance improvements for the whole site, especially in high-traffic events.
This rearchitecture, as we’re calling it, also connects reader data handling in Newspack Campaigns to other Newspack products. We’ve implemented a centralized Reader Data Library in the main Newspack plugin, which will serve as a source of truth about reader data we collect across our products, that can be read from or updated by all Newspack products. This Reader Data Library will make it easier for features like targeted Campaigns messaging to seamlessly interact with non-Campaigns features like content gating, analytics collection, and more.
What to look out for
The changes in this rearchitecture are mostly technical, meaning that the experience of using Newspack Campaigns shouldn’t change much for publishers or readers at this point. In fact, if we’ve done our job right, your readers won’t even notice that anything has changed. But the technical changes set us up for making bigger changes much more easily in the future. We’ve made our code leaner, more efficient, and more readable, cutting over 6,000 lines of code without losing any major features.
Some changes which you should be aware of:
- The “Segmentation Reach” feature, which provided a rough estimate of what percentage of your audience a segment would reach based on historical reader data, has been deprecated in the Campaigns dashboard. This feature relied on storing reader data on the server. Now that reader data is mostly stored in -browser, it’s impossible to make this calculation—but we think the performance benefits of browser-based data storage far outweigh the usefulness of this feature.
- The Campaigns Analytics dashboard has been temporarily deprecated. This dashboard relied on data from Universal Analytics, which was sunsetted in July, so the data shown was becoming increasingly useless. We’ll revamp this dashboard with GA4 data in a future project.
- Reader activity data is now tied to individual browser sessions, or to a reader account. Readers who may have signed up for newsletters or made donations in the past without registering a reader account may be treated as new readers after this change. We’ve tried to seamlessly identify these readers and migrate their data when possible, but readers who visit your site in a new browser session or who haven’t visited recently may be segmented as new readers.
- Because of the above, we recommend enabling the Reader Activation System for your site. This will allow readers to register for reader accounts which will serve as the central repository for their activity data.
- Once readers have registered for an account, they can log into that account to update their segmentation info. For example, if a reader registers an account and signs up for a newsletter, then closes their browser session, they can log into their existing account in a new browser session and still be recognized as a newsletter subscriber.
- If unregistered readers affected by the migration register an account using the same email address they used in past activity, in most cases they will be segmented properly from now on.
Take a look at the full changelog if you want to see the nitty gritty details of the rearchitecture. Help documentation will be updated incrementally over the next several weeks, so please be patient if you see outdated documentation on the help site in the meantime.
The Campaigns Rearchitecture is the most significant change in this week’s releases, but we’ve also made numerous smaller bugfixes and improvements, including updating a WordPress admin menu item from “Reusable Blocks” to “Patterns”, which reflects a major change in WordPress 6.3 that combines what were formerly known as Reusable Blocks and Block Patterns into a single concept called Patterns.
Next release cycle
Our next release is planned for the week of US Labor Day. Until then,
– The Newspack Product team