justinkendra - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Placement of API technology in a workflow is a philosophical decision

Listen to this podcast

Getting the most out of API technology is more than good design. It requires an understanding of who its beneficiaries are and where it is placed in a data analytics workflow.

Is it possible to know what lies in the mind of a business's customers? In this podcast, Will Thiel, director of analytics technology at Pointillist, says yes. Based in Boston, the company uses analytics to reveal what it calls the "critical paths" that consumers take as they engage with a brand across multiple channels -- app, web, phone, email, brick-and-mortar -- and over an extended time. The goal is to blend that information with applied analytics to predict what customers will do next. API technology is key to bringing the pieces together.

Will ThielWill Thiel

"Pointillist is a customer journey analytics platform," says Thiel. "It enables the analysis of cross-channel events." Thiel says the idea is to collect all the actions a customer takes and combine them into a larger lifecycle story. Pointillist takes those events, regardless of their nature or point of origin and melds them into an "analyzable package."

Analyzing events, regardless of the context in which they occur, is a difficult challenge, Thiel says. The original use case of Pointillist was attempting to discern embedded patterns within a collection of customer behaviors across all of a retailers various engagement channels. "As we explored deeper and deeper, we discovered the things we wanted to accomplish couldn't be accomplished with existing technology. We couldn't mine the insight out of that data with anything less than our own home-brew analytics."

Where you put [an] API, how close it is to the end user or to the technician delineates how much work has to be done by the end user or the engineer.

The obvious solution was to create a product capable of performing the required analysis, but with two key aspects: It had to be highly scalable and had to be implemented in a manner that could be packaged and sold to outside clients. In addition, Thiel says the analytics engine not only looked for predetermined patterns, but it was also able to discover behavioral patterns whose prior existence was unknown. "We allow users to walk through data and find things they didn't know were there," he says. Any update to that customer information is also treated as an event. "Our API challenge was defining the philosophies that our APIs were going to work inside of."

Through implementation of this unique API technology, Pointillist allows its customers to "walk through" their data and customers behaviors.

Philosophical API technology

As an event-driven analytics engine, all of the data collected needs to be in "event form," Thiel says. The challenge in designing an API for accessing the data was less about technology and more about the philosophical approach that Pointillist wanted to take. "When we decided that all the data was going to be events, that was a bold claim." Even static customer data is treated as an event. After all, Thiel says, it had to be created and recorded at some point in time, and that constitutes an event.

The data input side was always intended to be exposed to Pointillist's customers as a product. The analytics side features a query capability which is based on a separate proprietary API. Currently, this "story API" is designated only for internal use, but the company is formulating plans to open up this API for third-party developer use.

Though Pointillist is applying API technology in a unique manner, certain principles apply to any developer who works with APIs. It's not just the technical implication of which developers must be aware, but also larger implications for the company's products and strategic implications. The most basic of the implications, Thiel says, is the way that an API works as a delineation between two groups. On one side is the raw information handles with a "feeder API" while on the other side is output to the user. "Where you put that API, how close it is to the end user or to the technician delineates how much work has to be done by the end user or the engineer."

Joel Shore is news writer for TechTarget's Business Applications and Architecture Media Group. Write to him at jshore@techtarget.com or follow @JshoreTT on Twitter.

Next Steps

How do you measure event-driven success?

Know where to place APIs in a microservices architecture

Interfaces are crucial in successful API design

Best practices for API version management

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you determine the business functions that will be built into an API?
Cancel

-ADS BY GOOGLE

SearchAWS

TheServerSide

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

Close