Merge branch 'master' of github.com:sheac/in-app-event-collector into baconize-redis

Author: sheac

README.md

@@ -2,3 +2,35 @@ in-app-event-collector
 ======================
 
 Simple version of a server that collects in-app events sent from (mobile) devices
+
+The main idea is to borrow all the requirements from the old YMC Network app that served this purpose and then build version 2, but using the Functional Reactive Programming paradigm, instead of callbacks or promises. This effort has the blessing for CTO of the company Dr. Sandy "Ing" Shen.
+
+I feel like FRP is a great approach for this product, since the requirements are so easily conceptualized as incoming streams of data that need to be filtered, modified, merged, etc.
+
+The following is a subset of the requirements of the existing project. My plan is to go down the list, one-by-one, satisfying the requirements as I have time.
+* Must track a list of legal app ids by:
+  * Querying the central auth server for the list upon startup and storing that in memory
+  * Recieving requests from the central auth server that inform of new legal app ids and updating the in-memory list
+* Must receive JSON-formatted in-app events
+* If the `YA0token` property on the event is a legal app id, then it must store the event data in the `events` collection of the MongoDB database
+* Processing the incoming events as follows:
+  * Add a `time` property that indicates the current time
+  * If the event records a purchase, translate from the local currency into USD and include it as the `YA0USD` property
+  * Record the IP address of the device in the `ip` property
+  * if both:
+     * the `num_retries` property is present and greater than 0, and
+     * the `ctime` property is present and `time - ctime < 1 week`
+  * --> then use the value of `ctime` for `time`
+  * If the `YA0debug` property is present and "truthy", store the event in the alternate `sdk_debug` collection
+* Must manage the storage of traffic attribution postbacks as follows:
+  * If a postback arrives on the postback endpoint:
+    * Try to match the postback data to an existing `YA0birth` (first-launch/install) event in the `events` collection
+    * If no match is found, standardize the data and store it in the `postbacks` collection
+    * If a match is found, add the 3rd party tracker-specific attribution data to the matching event
+  * If an event arrives on the event endpoint:
+    * Try to match the event to an existing document in the `postbacks` collection
+    * If no match is found, store the event as usual
+    * If an event is found, add the 3rd party tracker-specific attribution data and then store
+  * The goal of storing the postback data is so that we can determine which traffic channels are responsible for which in-app events, and report this information to the marketing and production team 
+
+Of course, for now, the app is mostly just me getting my feet wet with server-side FRP, but stay tuned!