After reading it I had a thought crystallize in my mind that I had only fragmented pieces of before: The solution to this whole fake news explosion isn’t filters: it’s education. Crackdowns by platforms (Google, Facebook, etc) won’t help. If they crack down people will continue to put their trust in platforms to deliver them “real news” — meaning any fake news they see on a platform that doesn’t crack down — or a piece that makes it through a platform that does crack down’s filter, might very well be perceived as legitimate. I mean, the platform is filtering fake news so this article must be real, right?

I think the solution here is the same one that we really need to start leveraging more heavily in society: education. If humans have a built in filter in their brains (powered by critical thinking), then they are empowered to accurately decipher what is legitimate and what is not themselves without the need for some central authority to do it for them.

Platform filters, chrome extensions and the like will certainly help save many human hours of interpretation of bullshit news, but they (in my humble opinion) will not solve the problem. Educate. Educate. Educate. There is no other way forward my friends.

p.s.: To be clear, I could use some of this education myself. I certainly don’t believe I’m infallible and I have certainly believed some “fake news” in the past. And when I did, it was quite simply because I didn’t take the time to properly investigate the source and think critically about its legitimacy. We all need to work on this together.

The NPR piece: http://www.npr.org/sections/alltechconsidered/2016/11/23/503146770/npr-finds-the-head-of-a-covert-fake-news-operation-in-the-suburbs

Funnels are a powerful type of analysis for answering questions with multiple stages, such as user retention and drop-off, attribution analysis from referrals and campaigns, advanced user targeting, and more.

With Keen, there’s no limit to the range of custom funnels you can build. But previously, you had to write code to get the results. Now, you can quickly build any custom funnel in the Explorer, like this:

Need more steps? No problem. Here’s an example of a custom 5-step funnel:

You can learn more about using funnels in our docs or our Intro to Funnels Guide. But funnels aren’t the only thing we’ve added.

So what else is new in Data Explorer 2.0?

For those of you that don’t know, the Data Explorer is a point-and-click interface for querying and visualizing your event data. It interacts directly with Keen IO’s custom analytics APIs. Since the initial release of the open source Explorer, we’ve made a bunch of improvements, including:

A visual refresh

We’ve restructured the Explorer’s interface and made buttons easier to find and understand. We’ve also smoothed out the rough edges and made the entire query builder and visualization area more cohesive and consistent.

Support for saved and cached queries

The new Explorer lists out all your project’s saved and cached queries for easy loading, and it also lets you create new ones, edit existing ones, and delete any you no longer want. You can get all the details in this blog post.

A boatload of bug fixes

We’ve fixed quite a few little bugs that have popped up since our initial open source release, so the Explorer is running smoother than ever.

What else would you like to see?

We’re excited to be working on the Explorer out in the open and we’d love for you and your team to participate in making this project more useful for everyone! Feel free to log an issue for a bug you’ve found or an improvement you think makes sense. And of course, we’re always open to pull requests for bug fixes and improvements.

So what are you waiting for? Try out Explorer 2.0 for free on Keen IO or download the latest from Github, NPM, or our CDN. Check out https://github.com/keen/explorer for all of the Explorer usage options.

Questions? Reach out to us or ping us on Slack!

Happy Exploring!

Announcing Data Explorer 2.0 — Build custom funnels without code! was originally published in The Event Log on Medium, where people are continuing the conversation by highlighting and responding to this story.

I was recently chatting with a friend about event tracking for a mobile app he’s building. The more we spoke, I realized that many of the concepts that are important to ensuring you have clean, usable event data may not be second nature. Especially for people new to event analytics.

I’ve implemented event tracking many times in the last few years. And since joining Keen IO, I’ve had even more opportunity to see what works, and what doesn’t, for event analytics. So I decided to write up this list of common mistakes to avoid when getting started tracking event data — many of which I’ve made myself in the past:

1. Tracking events without knowing what questions you want answered

This is the single biggest mistake I see made. Teams rush into tracking events without having figured out what they’re trying to achieve. They end up littering tracking code throughout their codebase.

You need at least a rough idea of what answers you’d like to get out of your event analytics. Otherwise, implementing event tracking is a waste of your time. You will pay a hefty price for not thinking things through beforehand, in the form of unusable data and technical debt.

Take the time to figure out what questions you want your event data to answer and you’ll start off on the right foot.

2. Trying to track every single event

Many times I’ve seen teams take the approach of tracking every possible event. They hope that they’ll “cover their bases” and ensure they have all the data they need for future analysis. This is usually a symptom of mistake #1.

“Tracking everything” is not only impossible, but it in no way guarantees that you’ll have what you need to get answers. Additionally, it’s a lot of work! Wouldn’t you want to avoid doing unnecessary work?

You may still need to track a large amount events. But without knowing the end result you’re after, you’ll end up with a tons of unneeded tracking code and unusable event data.

3. Putting technical details in event names

I often see people put technical implementation details into their event names. The most common one I see is adding the tracking location. It’s usually best to leave technical details out. Take the following event name for example:

trackEvent(“UsersController:Opened Some Item”, {
 …event properties…
});

What value do you get from the “UsersController:” part of that event name? Is it helping answer questions about what’s happening in your application? If not, it’s just making things more difficult to read when you run your analytics.

Remember; the underlying technical implementation may change. Maybe Opened Some Item is tracked from the UsersController now, but it may not be in the future. When the location changes, so will the event name. Now you’ll have two different event names to reconcile when running your analytics.

If you need the controller name, add a key called controller_name to your event’s properties. This will make sure your event name stays the same even if the place you’re tracking it changes. And you’ll still have access to that data when you run your analytics.

Here’s a better way to do it:

trackEvent(“Opened Some Item”, {
 controller: “UsersController”,
 …more properties…
});

4. Not defining any conventions for event and property naming and structure

Consistency is just as valuable with code style as it is with event data. Too often teams start tracking events without having agreed on how to name them and structure the properties.

Without agreed upon conventions, you’ll have one developer track events like this:

trackEvent("User Signed Up", {
    "user": {
        "id": 123,
        "email": "joe@gmail.com",
        "user_type": "enterprise"
    }
});

and another developer track a different event like this:

trackEvent("user_clicked_toggle", {
    "user_id": 123,
    "email": "joe@gmail.com",
    "user_type": "enterprise"
});

This is probably obvious enough to you to demonstrate the reason why you need conventions. Without conventions your team mates will not track events with the same structure and you’ll end up with difficult to use data.

What do I mean by difficult to use data?

• A property in a given event may not even exist in another event. Meaning you can’t even run your desired query at all.
• A property in a given event may be named completely differently in another event. Meaning you’ll have to double check with your team mate and/or source code to ensure the events are indeed the same.
• A property in a given event may be in a completely different location in another event. This means you’ll need exceptions in your source code for every event that’s different.
• A given event may not have the same name as another event that actually represents the same action. Meaning you’ll technically have two separate collections of events, making every query you run more difficult.
• Different event and property names means the labels on your charts won’t be the same, even though they represent the same data.

If your properties look different for every event, running queries gets much more difficult. You need to know that for one event, a property might be named a certain way and live at the root level of the properties object, but for another event, the property may be nested several levels deep and be named something completely differently.

You may also send data with an event that one of your team members does not. This means you’re now missing data completely and will be incapable of running certain queries at all.

5. Separating the same event into several different events

I’ve seen many people track events with naming patterns like this:

“Viewed Signup Page”
“Viewed Product Overview Page”
“Viewed Account Profile Page”

Do you notice a similarity here? They’re all just types of the “Viewed Page” event.

It’s likely that all the above events will have the same set of properties. Instead, track just the “Viewed Page” event and add a “type” or “name” property containing which page they viewed.

This will make reasoning about your event analytics much easier. You‘ll have fewer event types to work with less work to get the answers you’re after.

Most analytics software has an easier time working with fewer event types. Only separate events into different types when they are truly different events.

6. Only tracking events for the short term

It’s common for people new to event analytics to track only things they need right now. With event data, it’s always best to to think a few steps into the future.

You might only need events x, y and z to get answers to the questions you have today, but what about a few months from now? What questions will you have then and what data will you need to answer them?

If you don’t start tracking those events now, you won’t have the data to answer the questions you’re going to have down the road. Ask yourself, “What will we want to know 3 months from now? What data will we need to answer those questions?”

This is a difficult task, as anyone who’s tried to predict the future knows. But you should at least make an effort to get ahead of the curve and be ready for the important questions you’ll have soon.

That’s it! If there’s anything I missed or if you’d just like to discuss more, hit me up on twitter @theericanderson or start a discussion on this article. You can also find out more about Keen IO.

Tracking Event Data for Newbies was originally published in Data informed on Medium, where people are continuing the conversation by highlighting and responding to this story.