Event website builder and analytics

With the help of Ana, the other designer in the team, I had previously conducted a series of activities with clients to map the whole event organization process. We were able to identify a series of problems in what we defined as the promotion and registration stages. These were the two main touchpoints we considered for the new product, but we still needed to narrow our scope.

We then started a series of interviews and a questionnaire to expand our knowledge on the problems we had identified so we could prioritize what solution we would be working on. Based on the new research, we discarded working on the registration process. The main complaints were about payment methods for B2B sales and tax compliance. Since the tax system in Brazil is complex and we would need to study it more, I decided that it was too risky to dive into this with the timeline we had.
‍
On the promotion stage, we identified that event marketing teams mainly depended on technology teams or digital agencies to manage the event website and had little control over analytics data to measure the efficiency of their campaigns. Almost all of the organizers responded they had Google Analytics or a similar tool for the event website, but would not use it because it was too complex or they needed someone from another team to provide them with the data. We decided to focus on a solution that could free them from this dependency and that would simplify their efforts when managing campaigns and media investment.

Until that moment, mobLee’s platform was completely built around the event app. Even the lead retrieval solution, a product sold separately, was treated as a feature of the app itself. I decided to dedicate time to working exclusively in the web platform navigation. 
‍
We needed to include the new product on the platform and prepare it for the long term strategy of expanding the product offerings. All products should be integrated around the event information, but should also work separately without direct dependencies. The products should be good by themselves, but better together.
‍
The solution we found for it was to have layers of functionalities, as shown in the diagram below.

The website builder would be treated as an external tool. Because the customers would be dealing with layout and a lot of information, I decided that it would be better to move them to an area with a cleaner interface where they could focus on the task at hand.
‍
Another important point was the shared event content. From the website builder tests, we identified that in the landing page setup we were asking for information that was already used in the event app. In order to avoid duplicate work, all the event content that could be shared between products was moved to a new area. When setting up each product, this content would be integrated into it.
‍
Because of time constraints, we decided that for the launch version, the content to be shown on the landing page would not be customized. For example, if a Speakers section was used, it would always show all speakers in alphabetical order, mimicking the behavior of the same list that appeared in the app. The ability to organize the speakers and other content lists according to other rules was appointed to be reviewed after launch.

The first step in the product use was to create the event landing page and publish it. With the page live, organizers could then track all their visits, analyze what are the most common visitors’ source and their conversion to ticket sales. By keeping up with these numbers every week and defining goals, they could make tweaks to the page and their campaigns to improve conversion while releasing new event content.

The page would be built from a pre-defined template with the most common content sections for the type of event created and with clear call-to-action buttons. For orientation and a quicker setup, basic event information such as the event name, date, and venue were already filled in appropriate areas. The organizer would be able to customize text, colors, images, and media, add new sections and rearrange them.

Even though a big portion of the event websites’ access was from mobile devices, the mobile version of these sites was often overlooked. Our layout was made to be responsive and while building the page, the user could preview how the page would look on a desktop, tablet, or even a smartphone. To optimize the page loading time, there were also options for hiding some types of media on the mobile version.

The page structure was compliant with Search Engine Optimization best practices and our Customer Success team was trained to provide orientation on how to improve the use of keywords throughout the page. Small teams had little experience in preparing their website for Google’s search ranking and this was important to help them improve their organic reach.

The product tracked every visit to the website and every click in a registration button and, with integration or manual input, it could also track the final registration numbers, calculating the conversion rate between these 3 steps. Based on these metrics, organizers could plan efforts to improve their results. They would be able to highlight content to motivate visitors to buy tickets or make promotions to capture those giving up in the registration phase, for example.

Using referrers and UTM parameters in the URL, the product would keep track of metrics for individual acquisition channels: email, social network, ads, external referrals, organic search, direct access. Each channel was broken down into campaigns or referrer, making it possible for organizers to measure the results of each campaign and their return over investment.

We soon realized we had oversimplified the acquisition channels report. For organizers that were not used to analyzing this kind of data, it was a whole new world of discovery and enchantment. On the other hand, more experienced event marketing teams already had particular ways of dealing with campaigns and often times would use very specific utm parameters that our system could not recognize. We then reworked the report to better group channels and create new mediums based on the custom parameters the event teams set up.

Our changes to the platform navigation had a secondary objective of raising awareness in our customer base that the company had other products besides the known event app. We first used the name of the products in the interface, and that proved to be confusing, especially because the names were in English and did not fit our Latin American users. We later changed the product labels in the navigation to more straight forward labels that described each product.
‍
Selling the solution to our current customers was challenging because of timing. The event app was usually hired 2 to 4 months before the event. At that time, all the promotion efforts were already ongoing, so we needed to wait for the next event cycle.
‍
Customers requested constantly the ability to add other tools to the website, like the Facebook Pixel and Chat solutions. We decided to integrate it with Google Tag Manager, openning the range of tools that could be used in the website without a big development effort.