Social Analytics is a philosophical perspective developed since the early 1980s by the Danish idea historian and philosopher Lars-Henrik Schmidt. The theoretical object of the perspective is socius, a kind of “commonness” that is neither a universal account nor a communality shared by every member of a body. Thus, Social Analytics differs from traditional philosophy as well as sociology. It might be said that the perspective attempts to articulate the contentions between philosophy and sociology. The practise of Social Analytics is to report on tendencies of the times. It does not aim to make a diagnosis of the times that can be agreed upon by everyone or anybody but a report that no one wants to protest about.
See more on http://en.wikipedia.org/wiki/Social_Analytics
Here at Social Report we use a basic ticketing system that allows customers ask questions and allows us to track our response to them. Each ticket is a conversation. This setup is quite standard and simple to manage. With emergence of social networks as means of communication many companies communicate with their customers using Twitter (among other options).
A customer may tweet “Hey @SomeCompany – I having a problem with my account” and the company may respond “Hello @TheCustomer, sorry, can you let us know what specifically is not working?”. You get the idea.
The problem is that unlike traditional form of communication (did I just call email – traditional? J) – this chat ends up being seen by all of your followers. Is this ideal? Your customer’s question was not visible to your followers. Your response is however! If you are using your Twitter feed as means of communicating with your followers about your product, latest news, news features. When someone follows you on Twitter in some ways they are entrusting you with being respectful of their privacy. The will most certainly stop following you if you start abusing this trust. This customer support inquiry response may be the noise that your followers simply don’t need. They may also get annoyed. So basically while you were trying to help one customer you just annoyed all others.
Would you be interested in hearing about another person’s issue? Probably not! It is obviously somewhat subjective – some may argue that fostering conversation is a great community building tactic. This is what may get others to take part in discussions. Others may however say that information overload is a big issue already – that figuring out a way to only see information that is relevant to you is difficult as it stands.
To be completely fair however certain questions and responses are great for all to see. This may indeed be appropriate for us and not appropriate for others. Just considers all pros and cons when deciding to support your customers using any social media platforms.
A single index is already a major step forward, but what happens when we need to have more than one index. There are many cases for using multiple indices, an example can be storing an index per week of log files indexing, or even having different indices with different settings (one with memory storage, and one with file system storage).
When we do that though, we would like to be able to search across multiple indices (among other operations).
Indexing data is always done using a unique identifier (at the type level). This is very handy since many times we wish to update or delete the actual indexed data, or just GET it. Getting data could not be simpler and all that is needed is the index name, the type and the id. What we get back is the actual JSON document used to index the specific data, but please, keep it secret and don’t tell any other distributed Key/Value storage systems…
elasticsearch is schema less, just toss it a typed JSON document and it will automatically index it. Types such as numbers and dates are automatically detected and treated accordingly.
But, as we all know, Search Engines are quite sophisticated. Fields in documents can have boost levels that affect scoring, analyzers can be used to control how text gets tokenized into terms, certain fields should not be analyzed at all, and so on… . elasticsearch allows you to completely control how a JSON document gets mapped into the search engine on a per type and per index level.