# What’s the difference between the Email and Web channel in marketing automation? GetResponse Marketing Automation now supports two distinct channels: **Email** (subscriber-based) and the newly introduced **Web** (visitor-based). These channels differ in how they track and interact with users, as well as how workflows are executed and managed. ![explanation of the difference between Email and Web chanel in GetResponse Marketing Automation](https://us-wd.gr-cdn.com/help/sites/9/2025/06/0933/CleanShot-2025-06-30-at-11.33.10-2x.png) Until now, marketing automation in GetResponse has been based on **subscriber processing**, where the primary identifier was the **subscriber ID**. We’re now introducing a new channel: **Web**, where workflows run directly in the customer’s web browser. These flows do **not require subscriber context**, because the main identifier is the **visitor’s UUID**, stored in the `gaVisitorUuid` cookie. [The execution of the automation cycle in the Web channel is handled by the WebConnect script running in the user’s browser.](https://www.getresponse.com/help/what-is-web-connect-and-how-can-i-use-it.html) A visitor doesn’t need to be an identified subscriber to enter a workflow in the Web channel. When should I use the Web or Email channel ------------------------------------------ Use the **Email channel** when your goal is to engage with **known contacts** from your email list – for example, to send follow-ups, tag subscribers, or trigger actions based on email behavior or purchase history. Use the **Web channel** when you want to **engage anonymous or identified visitors directly on your site**, such as showing popups, prompting for push notifications, or reacting to web behaviors like visited URLs or liked/viewed products. Below, we explain all the key differences between the Web and Email channels. Negative paths -------------- In the **Email channel**, condition elements can include **negative (red) paths** if conditions aren’t met within a specified time window. ![Message opened element and its settings showing how to configure the negative path when condition is not met](https://us-wd.gr-cdn.com/help/sites/9/2025/06/0938/CleanShot-2025-06-30-at-11.38.22-2x.png) In the **Web channel**, this option isn’t available. Instead: * If a visitor doesn’t meet the condition, they will **remain in the element for up to 30 days**. * If the condition still isn’t met after 30 days, the visitor is automatically **removed from the workflow**. **Cross-channel journey transfers** ----------------------------------- A journey is a single path through the automation graph. A single person may have multiple journeys within the same graph at the same time. While both channels can run side by side, **moving a person directly from one channel to the other within a single journey is limited**. 🔄 **From Email to Web – not supported** At this time, it’s not possible to transfer a journey from the Email channel into the Web channel. This means that if a person enters a workflow through an email-based condition, you can’t connect web elements later in that same path. If you try to add a web-based element (such as “Show popup” or “Prompt for push notification”) after an email-based path, the system will show a warning, and the automation won’t allow that configuration. ![warning message displayed when trying to add a web element to an email-based path](https://us-wd.gr-cdn.com/help/sites/9/2025/06/0944/CleanShot-2025-06-30-at-11.44.38-2x.png) However, you can still build automations that react to both subscriber and visitor behavior **by using multiple start conditions** in the same workflow – for example, one for when someone subscribes to your email list (Email channel), and another for when someone likes a specific product (Web channel). Each condition starts a **separate journey** within the same workflow graph. ![example of a workflow with two starting conditions, one from email channel, another one from web channel](https://us-wd.gr-cdn.com/help/sites/9/2025/06/0947/CleanShot-2025-06-30-at-11.47.28-2x.png) 🔄 **From Web to Email – supported** Transferring from a Web-based journey into the Email channel is possible, but only under one condition: the visitor **must be** **identified** as a subscriber. Visitor identification happens automatically when a user logs into your store or customer portal and your integration sends their email address and visitor ID (`gaVisitorUuid`) to GetResponse. Alternatively, you can identify visitors manually using the `GrTracking` method or by tracking link clicks. To learn more about the available tracking options and how to implement them, [see this article in our Help Center](https://www.getresponse.com/help/how-do-i-add-the-tracking-javascript-code-to-my-website.html). At the moment when the transfer is triggered, the system checks whether that visitor is already linked to a subscriber. If not, it will retry the transfer at gradually increasing intervals **over a period of about 30 minutes**. To help improve transfer reliability, you can insert the **“Email subscriber” filter** before the transfer. This checks whether the system can recognize the visitor as a subscriber based on data available in the browser. ![example of a workflow where transfer from web to email channel would be possible](https://us-wd.gr-cdn.com/help/sites/9/2025/06/0952/CleanShot-2025-06-30-at-11.51.59-2x.png) Adding existing contacts to a workflow -------------------------------------- In traditional **Email-based automation**, you can include contacts who are already part of your list before the workflow starts: ![automation setting to include contacts who are already subscribed before the workflow starts](https://us-wd.gr-cdn.com/help/sites/9/2025/06/0955/CleanShot-2025-06-30-at-11.54.42-2x.png) In **Web automation**, this type of manual entry is not available. Web workflows rely entirely on **real-time visitor behavior**. You cannot pre-load or import existing users into a Web-based workflow. Segmentation ------------ The **Web channel** currently does not support segmentation based on contact list data. The **Web channel** is a new functionality and is still under active development. We’re working on expanding its capabilities and adding more features in upcoming updates.