Skip to content

Commit aba8476

Browse files
committed
Update README.md
1 parent d05e805 commit aba8476

1 file changed

Lines changed: 32 additions & 0 deletions

File tree

README.md

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,3 +2,35 @@ in-app-event-collector
22
======================
33

44
Simple version of a server that collects in-app events sent from (mobile) devices
5+
6+
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 current CTO of the company Dr. Sandy "Ing" Shen.
7+
8+
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.
9+
10+
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.
11+
* Must track a list of legal app ids by:
12+
* Querying the central auth server for the list upon startup and storing that in memory
13+
* Recieving requests from the central auth server that inform of new legal app ids and updating the in-memory list
14+
* Must receive JSON-formatted in-app events
15+
* 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
16+
* Processing the incoming events as follows:
17+
* Add a `time` property that indicates the current time
18+
* If the event records a purchase, translate from the local currency into USD and include it as the `YA0USD` property
19+
* Record the IP address of the device in the `ip` property
20+
* if both:
21+
* the `num_retries` property is present and greater than 0, and
22+
* the `ctime` property is present and `time - ctime < 1 week`
23+
* --> then use the value of `ctime` for `time`
24+
* If the `YA0debug` property is present and "truthy", store the event in the alternate `sdk_debug` collection
25+
* Must manage the storage of traffic attribution postbacks as follows:
26+
* If a postback arrives on the postback endpoint:
27+
* Try to match the postback data to an existing `YA0birth` (first-launch/install) event in the `events` collection
28+
* If no match is found, standardize the data and store it in the `postbacks` collection
29+
* If a match is found, add the 3rd party tracker-specific attribution data to the matching event
30+
* If an event arrives on the event endpoint:
31+
* Try to match the event to an existing document in the `postbacks` collection
32+
* If no match is found, store the event as usual
33+
* If an event is found, add the 3rd party tracker-specific attribution data and then store
34+
* 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
35+
36+
Of course, for now, the app is mostly just me getting my feet wet with server-side FRP, but stay tuned!

0 commit comments

Comments
 (0)