Today we had a rather productive meeting with Engineering.com where we got a better idea of what they wanted when it comes to the front end API. We originally envisioned two options for tools. One would be a simple collection of prepared queries, the other would be a powerful graphical query builder. It turns out they don’t really care for a powerful query builder.
They’re more interested in the answers those prepared queries would provide, provided we spent a lot of time carefully making them so that the tool is useful for them long term. They also want a way to analyze the data we collected and calculate information that would be used to categorize the visitors. For example, an affinity score might be how well a certain user likes a certain category. Those variables can be integrated into their Elasticsearch system, and this augments their recommender engine.
This two-pronged approach, actively getting analytical answers and passively augmenting their recommender engine, is definitely the best way we can use the data we collected. The scope of this project is huge in terms of the number of applications we’ll be making. It seems there’s a new API being proposed every few weeks. But then again, splitting our application into multiple parts like this is probably a good way to organize things. It’s probably going to be flexible and easier to look at later on when it comes time to take useful work we’ve done and consider publishing it as open source software. All these APIs will be worth it!