The Dos and Don’ts: Designing Customer Event Systems

24 May 2018 RevIQ Hive Mind Leave a comment RevIQ

By now you know that RevIQ is all about optimization; specifically, revenue optimization. This is something that we look at through the entire life cycle of a product; through development, beta, launch, marketing, user acquisition, A/B testing and ongoing live operations. (Sorry, we get very excited and then we ramble 😛 ) Seeing through this lens gives us the unique opportunity to put our passion to paper through testing, iteration, and optimizing our own processes. And since sharing is caring, here are some insights into a very important approach in F2P games: designing custom event systems.

Lucky for you, this is actually one of our core offerings. We see designing custom events as necessary to maximizing business intelligence and informing ongoing development. One important consideration we always warn our clients about, is to frontload as much as possible. While adding new events is not a problem (it is quite necessary for changing and adding features), event data doesn’t regress, which means that data will only start collecting once the event is in the game. Depending on your audience size this can negatively impact speed of iteration while you wait for data collection.

As an example, we designed an enormous custom event system for a client. The client wasn’t sure what player behaviour trends they were looking for, so we wanted to be thorough and ensure that we captured everything! The game was still in its conception stage and our team continued adding new and changed events and payloads (parameters) for every additional feature and every conceivable question. We then used this data to visualize trends and answer questions from the client on a live, proprietary dashboard.

This worked very well for a while, and then the game started lagging, potentially because of the amount of data being sent back and forth. Fortunately, by this stage both the client and the RevIQ team knew the game and the vision well enough to be able to quickly cull unnecessary events and payloads. And as a team we were very happy to learn a few things from this experience:

What NOT to do:

  • Overly complex or bulky event systems can actually compromise players’ experience by taking up too much memory and/or bandwidth.
  • Uploading and storing too much data can take an enormous amount of time, and grow quickly and exponentially. This becomes an inefficient way to process in a highly competitive industry where pre-emptive and quick iteration is crucial to sustained success.

What TO do:

  • Custom events should always be informed by clearly articulated hypotheses. These hypotheses should aim to separate relevant data for high-impact design changes from the weeds.
  • Some initial questions that will inform these hypotheses include:  
    • Which mechanics, balances or features are you most concerned about?
    • How do you presume players will respond to different aspects of the game and why?
    • How would you want to test these assumptions?
    • Which features do you think players will want or want more of, but had to be cut out of the initial development scope due to time pressures? What data in the current version of the game could help inform or prove your gut feeling? (so that you can convince your executive team to let you see your awesome design through 🙂 )
  • Consider which parameters are necessary for each custom event to be meaningful. If there are some that are more generic and not necessary, cut them!

Once you’ve developed your hypotheses and designed your tests, it is important to check that your events are actually answering your questions and that the data you collect is reliable, valid and generalizable. That’s where our team of awesome comes in – contact us to find out more!


About the author: Riette is a fierce customer-focused strategist who is passionate about well-designed product. She is into nerdy crafts, loves cats, and has a laugh you can hear from a mile away.

Tags: , , , , ,

Like this article? there’s more where that came from.

Leave a Reply

Your email address will not be published. Required fields are marked *