Changes

==Current Counterfactual Variables== Version 2-2 of the dataset includes the following sets of variables:# firmappmoomirank,firmexitsrank,firmappexitmrank,firmappinvmrank,firmportcosrank,# firmappmoomiwrank,firmappmoomitruncwrank,firmappexitmwrank,# firmappmoomirankqtile,firmexitsrankqtile,firmappexitmrankrankqtile,firmappinvmrankqtile,firmportcosrankrankqtile,# firmappmoomiwrankrankqtile,firmappmoomitruncwrankqtile,firmappexitmwrankrankqtile The first set ranks the performance measures already in the dataset using only the 3542 VC firms in the dataset: apportioned MOOMI (firmapportionedmoomi), exits (firmexits), apportioned exit value (firmapportionedexitvaluem), apportioned investment (firmtotalapportionedinvm) and the total number of portcos invested in (firmnumportcos). The second set calculates weighted ranks or truncated weighted ranks (where 1 is the best and 3542 is the worst):* firmappmoomiwrank ranks firmappmoomi*(firmportcos/sumfirmportcos* firmappmoomitruncwrank ranks firmappmoomi*((CASE WHEN firmportcos <= 75 THEN firmportcos ELSE 75 END)/sumfirmportcostrunc)* firmappexitmwrank ranks firmappexitm*(firmportcos/sumfirmportcos) The third and fourth sets are the ranks above as quartiles (i.e., 1 is best, 4 is worst). By all means, play with the variables! My guess as to the "best" (i.e., closest approximation to true quality as measured by long-run returns) is (in order):* '''firmappmoomiwrank''': This puts all the most famous VCs in the top quartile and the bottom quartile truly sucks.* firmappmoomitruncwrank (harder to justify the truncation, so second place but gives higher rankings to successful small firms who face a pretty stiff size penalty in firmappmoomiwrank)* firmappexitmwrank: Doesn't take into account investment but still delivers a good result I also took a look at which types of firms to remove. It turns out that '''firmcat''' was already pretty well put together (i.e., I'd gone down that rabbit hole and excavated it). So, I suggest that we try the following components separately and then, depending on the results, consider the following groupings:* Corporate* PE* Ecosystem + Angel * Gov + SBIC ==Notes== This section provides notes on the analysis in Selected_prelim.do. I ran the code and did a basic exploration of variables. These are the results:* '''I couldn't make the sign on distance change.''' That's a real finding! I tried CA/MA fixed effects and interactions, Silicon Valley/Boston Cambridge fixed effects and interactions, using quadratic effects, various transformations... nothing undid the results. Also, log distance is the best variable.* matchinstagebroad outperforms matchinstagenarrow in some contexts, we should use it.* I tried logging all the vars, even t_pccitydollarsrankm1, to no avail.* pcexitvaluem is already set to 0 when exit=0. It is missing for undisclosed value acquisitions. '''It's a great RHS variable: Log it and use it!'''* I used mktid fixed effects and the results look pretty good without the interactions... but less good with them for the probit. There was a slight improvement for the reg, but only 2 vars are sig either way. I think maybe year ind is fine.* Doing value conditional on exit gave just 1 *** and 1 *. It's the exit that drives the sig in exit value. So, all in all, I say you're good to go with your 'best spec' if you want to keep the interactions: probit pcexit l_matchbodist matchinstagebroad c.l_firmageatdeal##c.l_pcexpceopres c.l_matchprevportcos##c.t_pccitydollarsrankm1 i.year i.ind if realmatch==1, cluster(mktid) However, '''the interactions are never significant'''. If you drop the weakest of the interactions (the one involving l_matchprevportcos*t_pccitydollarsrankm1), you're good to go for every variable except the remaining interaction, which is (almost) borderline (it's significant if your drop the industry fixed effects): probit pcexit l_matchbodist matchinstagebroad c.l_firmageatdeal##c.l_pcexpceopres matchprevportcos t_pccitydollarsrankm1 i.year i.ind if realmatch==1, cluster(mktid) Without interactions, the variables are all good: probit pcexit l_matchbodist matchinstagebroad l_firmageatdeal l_pcexpceopres matchprevportcos t_pccitydollarsrankm1 i.mktid if realmatch==1, cluster(mktid) A word on the interpretation of variables for the write-up:* l_firmageatdeal is our VC wisdom variable* matchprevportcos is our VC size variable* l_pcexpceopres is our PC team quality variable* t_pccitydollarsrankm1 is our PC environment quality variable ==Dataset Rebuild== This project uses [[VCDB20]]. In E:\projects\vcdb20\ * Load.sql* BuildBaseTables.sql* Ranking.sql Specific to this project:* BuildDataset.sql === V2 === ==== New dataset ==== The new file is: MasterCode20YearV2-1.txt. It's in the dropbox! ===== V2-1 Changes ===== There were some issues with bodistkm being rather extreme (i.e., ~6000-8000km):* A single portco, CodeHS had an incorrectly geocoded addresss. Despite being listed as San Francisco, CA, addr2 was "Babraham Research Campus", which Google Maps was incorrectly associating with the village of Babraham in Cambridge, UK. The address for this firm has been manually fixed (the correct address is 1328 Mission St, San Francisco, CA 94103) and its correct geocoding has been pushed through the tables (portcogeo, portcopoints, portcomaster, portcosuper) to the final dataset. CodeHS received its first round in 2012 and may achieve an exit but probably .* The remaining extreme values were caused by portcos or firms being located outside of the continental U.S. (i.e., in HI, AK, or PR). When such a firm was paired with a mainland firm, it would have an extreme distance. '''The dataset is now restricted to the continental U.S. The largest distances are now ME-CA pairs or WA-FL pairs, as expected.''' ==== Summary of request ==== Objectives: * Generate matchinstagenarrow and matchinstagebroad* Check coverage of Xunjie's variables* Generate some alternative/additional variables: Xunjie's list of variables for estimation:* matchhqdist -- matchbodist is preferred. was 152/500k nulls, should be done now.* matchinstagenarrow -- Now in the dataset with improved logic. Probably use matchinstagebroad instead. No nulls.* firmfirstinvyear -- firmageatdeal is preferred. No Nulls.* matchprevindu20 -- no nulls.* matchprevportcos -- no nulls.* pcnumperson -- this is a conceptually and operationally terrible variable! See below.* pccitydollarsrankm1 -- had lots of missing! This should be resolved now.* pcexp -- similar issues to pcnumperson. See below. Xunjie's Restrictions:* I only keep data between 2002 and 2016. * And I only keep the matching markets if the number of real matches is more than or equal to 5. * This gives me 922 matching markets.   "The major issue is that there are many missing values (about 10%) for the last three variables (and possibly “matchinstagenarrow"). We need to drop the entire matching market if there is one missing value. The number of matching markets without missing values is 260. So less than 1/3 matching markets survive." Dropping the entire market is surely way too extreme. We should just drop the offending portco and only drop the market if the number of real matches drops below our threshold (e.g., 5). I've included some new market stats to give analytics: mktdealcount, mktnumreal, mktnumsyn, mktnumfirms, mktvalid. ==== Review of Changes ==== In BuildBaseTables.sql:* Fixed PortCoGeoid to use zipcodes too to determine placename * Created separate geoid lookup table for place, statecode: PlaceStatecodeGeoid* Pushed changes through PortCoMaster* Added new vars to PortCoPeople and pushed them through. Added restrictions to MatchMostNumerous (34604) by creating a temp view RLMasterRestricted where:* Firm and portco nation code='US'* Firm and portco statecode code!='UN'* Code is not null* placename is not null* hqdistkm is not null In Ranking.sql* Re-run with updated portcogeoid!* Pick up Geoid from new PlaceStatecodeGeoid table (BuildBastTables.sql) In BuildDataset.sql. * SynthKeys_Code20: Pushed changes through. 488065* ComboKeys_Code20: 522669 = 488065 + 34604* PortCoSuper (not restricted) - uses lastest version of PortCoMaster. Placename from PortCoGeoid, which uses zipcodes too. DealSuper (restricted to MatchKeys!), FirmSuper (now US only, but not restricted)* Combodist, ComboIndu, and ComboMeasures tables (all based on ComboKeys_Code20) much as before but with new base sets* ComboStats_Code20 added to provide market info.* MasterCode20Year. Rerun with new feeders. New variables added. ==== pccitydollarsrankm1 ==== There are a number of possible explanations for why this variable had lots of missing.  There do seem to be missing placenames. 4855/69882 PortCoSuper records don't join to PlaceYearRanking on placename and state (ignoring year) and 4,561 of these have valid zips. However, only 263 had growth VC and just 82 has non-null positive invested amounts, so this isn't the issue.  Ultimatately, I rebuild the underlying tables (portgeoid, etc.) and created a new lookup table (PlaceStatecodeGeoid), and then reran the rankings making sure to keep the "no activity" places for each year (tied for last place). The ranking variables should be fixed now. ==== pcnumperson / pcexp ==== pcnumperson suffers from a number of endogeneity issues, including:# Thomson adds information each time the firm recieves more investment, so pcnumperson is correlated with the number of rounds, amount invested, prob of exit, etc.# Higher quality firms/portcos are more likely to report the people in a portco. # numperson includes a broad range of titles, roughly VP-level and above with some extras, and more organized portcos may report deeper into their ranks. # It's possible that some non-exec board members are included pcexp suffers from all of the above issues and more. pcexp has the following lineage:* portcosuper.pcexp <- prevs.PortCoPeopleMaster <- sum(prev).PortCoPeopleAgg <- COALESCE(sum(hasperson),0).PortCoPeopleSerial <-hasperson.PortCoPeopleKey <- hasperson.PortCoPeopleFull <- hasperson.PortCoPeopleBase* PortCoPeopleBase: CASE WHEN prefix IS NULL AND firstname IS NULL AND lastname IS NULL THEN 0::int ELSE 1::int END AS hasperson,* So hasperson is a record indicator, and the pcexp sums over both people and thier positions. Accordingly:** A portco with 1 person who has held two previous positions has pcexp=2** A portco with 2 people who have each held one previous position has pcexp=2* Non-exec board members (lawyers, investors, etc.) may have worked with lots of previous firms and be inflating this count! I rebuilt these variables so that they have better coverage where possible. I also set doctors, serials, serialceopreses, serialfounders, prevs, prevceopreses, prevfounders to zero when missing in PortCoSuper (I left them as null in PortCoPeopleMaster).  We shouldn't use numperson at all. It's just horrible. Instead we should try one of the following:* serialceopreses* serialfounders* serials* doctors (maybe for something different)* prevceopreses* prevfounders  But I expect that you we have problems with variation. ==== match in stage ==== New logic makes 'matchinstagepref' (both narrow and broad) true when stagepref is null, the deal is sead/early and the firm is 'Ecosystem','SBIC','Angel','Gov', and otherwise when stagepref is null.  CASE WHEN (dealseed >= 1 AND (firmstageprefno=1 OR firmstageprefno=3 OR firmstageprefno=5)) THEN 1::int WHEN (dealearly >= 1 AND (firmstageprefno=2 OR firmstageprefno=3 OR firmstageprefno=5)) THEN 1::int WHEN (deallater >= 1 AND (firmstageprefno=4 OR firmstageprefno=5)) THEN 1::int WHEN firmstageprefno IS NULL AND firmcat IN ('Ecosystem','SBIC','Angel','Gov') AND (dealseed >= 1 OR dealearly >= 1) THEN 1::int WHEN firmstageprefno IS NULL AND firmcat IN ('Ecosystem','SBIC','Angel','Gov') AND NOT (dealseed >= 1 OR dealearly >= 1) THEN 0::int WHEN firmstageprefno IS NULL THEN 1::int ELSE 0::int END AS matchinstagenarrow, CASE WHEN (deallater >= 1 AND (firmstageprefno=1 OR firmstageprefno=2 OR firmstageprefno=3 OR firmstageprefno=5)) THEN 1::int WHEN (dealearly >= 1 AND (firmstageprefno=1 OR firmstageprefno=2 OR firmstageprefno=3 OR firmstageprefno=5)) THEN 1::int WHEN (deallater >= 1 AND (firmstageprefno=4 OR firmstageprefno=5)) THEN 1::int WHEN firmstageprefno IS NULL AND firmcat IN ('Ecosystem','SBIC','Angel','Gov') AND (dealseed >= 1 OR dealearly >= 1) THEN 1::int WHEN firmstageprefno IS NULL AND firmcat IN ('Ecosystem','SBIC','Angel','Gov') AND NOT (dealseed >= 1 OR dealearly >= 1) THEN 0::int WHEN firmstageprefno IS NULL THEN 1::int ELSE 0::int END AS matchinstagebroad, ==== Other ==== I added together the patents and SBIR grants pre and during VC to create the following variables (each has variation issues, but maybe try in order):* pchaspatentsvc (1/0 indicator for portco has patents)* pcpatentsvc (number of patents)* pcsbircountvc (number of SBIR grants)* pcsbiramountvc (value of SBIR grants) === Changes to date === Code is in E:\projects\unobservedcomplementarities\BuildDataset.sql Changes:*Changed MatchHighestRandom to MatchMaster. It is MatchMostNumerous (i.e., pick the firm with max(numportcos) for each portco from RLMaster) with a random tie break. It contains a lot of variables pertaining to the portco, firm, round, and match!*MatchKeys is coname, statecode, datefirstinv, firmname, as well as minroundin, year, code, code20, code100. It replaces RealMatchesCode.*Replaced SynRealSetc20 with SynthKeys_Code20.*Replaced AllRealMatchKeysC20Code with ComboKeys_Code20, also renamed realmatch variable to isreal.**Note that ComboKeys_Code20 (591,299 with 554,561 synths) is much smaller AllRealMatchKeysC20Code (1,631,896 with 1,599,427 synths), which allowed (almost) any other firm from RLJoinerFF that had done a deal in that code20-year. ComboKeys_Code20 only allows another real match from the same code20-year.*Rebuilt Super tables (PortCoSuper, DealSuper, FirmSuper). Note that FirmSuper is now restricted to US firms only (matches were already US-US because MatchMostNumerous was constrained to US (and state !='UN') firms and portcos only. However, it is not clear that this was true in the past.).*Rebuilt the AllMatchc20 tables. New names are Combo..._Code20. **Crucial difference: Only investments within ComboKeys_Code20 are included in the history counts. Before anything in RLJoinerFF or even RoundlineBase were included, which created the impression of overcounts.**The vast majority of missing distances were caused by missing firm addresses for just 391 VCs (some of these were state UN, and later removed). However, we have zip codes for almost all of them. I built firmbogeoplus (see [[VCDB20]]) to add in zcta centroids from the U.S. Census gazetteer where available. However, 47 zips weren't in the ZCTA lookup, and they account for 113 firms that participated in 3,997 pairs (real and synth). So I also ran GeocodeOneKey.py with a (no header) Zip\tZip input (MissingFirmZips.txt), manually added three records (02801,85292,91399) and loaded up the result as zipgeoaddon (from MissingFirmZips-Geocoded.txt) in Load.sql.**Also required that matches have a code(/20/100)**Changed the Experience table to count experience in previous years rather than previous rounddates, as then experience doesn't change within a market except through the match.*Changed the join to the ranking. New build uses PlaceYearRanking, and joins on placename, state, year (placename is available in PortCoSuper).**There was an error with Centerville Ohio appearing in the ranking twice each year from 1998 to 2001.  SELECT hasgeo, COUNT(*) FROM ComboDist_Code20 WHERE bodist IS NULL GROUP BY hasgeo; /* firm 52 none 4 pc 10444 */ Note: The following are available in firmbasecore but unused in firmvars: SELECT invstatus, rolepref, geogpref, indpref, stagepref FROM firmbasecore; SELECT invstatus, count(*) FROM firmbasecore group by invstatus ORDER BY invstatus; Actively seeking new investments 10856 Inactive / Unknown 1625 Making few if any new investments 68 Reducing investment activity 48 1257 SELECT rolepref, count(*) FROM firmbasecore group by rolepref ORDER BY rolepref; BO 965 DO 340 EI 757 OH 10 OT 131 11651 SELECT COUNT(*) FROM ( SELECT geogpref, count(*) FROM firmbasecore group by geogpref ORDER BY geogpref) AS T; --181 --Includes, states, nations, continents, etc. SELECT COUNT(*) FROM ( SELECT indpref, count(*) FROM firmbasecore group by indpref ORDER BY indpref) AS T; --112 --COULD MAYBE BE CODED IN TERMS OF CODE20, etc. ===Review of old dataset=== Anticipating a dataset rebuild, the old production dataset was '''MasterRealC20YearFullPlus.txt''', which was produced using: E:\projects\vcdb3\MatchingEntreps2VCs\MatchingVCEntrepRevisions.sql This seems to have an error in the construction of '''matchinstagebroad''' l129. MasterRealC20YearFull requires:*AllRealMatchKeysC20Code <-RealMatchescode, AllRealMatchKeysC20; AllRealMatchKeysC20 <-SynRealSetc20,RealMatchescode; SynRealSetc20 <-RealMatchescode; RealMatchesCode <-MatchHighestRandom, PortCoIindustry (RevisedDbaseCode.sql)*PortCoSuper <- likely new PortCoMaster*DealSuper: Would need to be rebuilt*FirmSuper <- likely new FirmVars and FirmGrowthPerf*AllMatchc20Dist <-AllMatchc20DistBase (RevisedDbaseCode.sql); AllMatchc20DistBase <- AllMatchKeysC20, portcogeo, firmbogeo; AllMatchKeysC20 <-RealMatchesCode, SynSetc20.*AllMatchc20InduHistWZero <- AllMatchKeysC20Code, AllMatchc20InduHist ... RoundLineMasterBase (RevisedDbaseCode.sql)*AllMatchc20InduTotal <- AllMatchKeysC20Code, RoundLineMasterBase (RevisedDbaseCode.sql) *rankingfull <- likely new placeyearranking Code for matchinstagenarrow CASE WHEN (dealseed >= 1 AND (firmstageprefno=1 OR firmstageprefno=3 OR firmstageprefno=5)) THEN 1::int WHEN (dealearly >= 1 AND (firmstageprefno=2 OR firmstageprefno=3 OR firmstageprefno=5)) THEN 1::int WHEN (deallater >= 1 AND (firmstageprefno=4 OR firmstageprefno=5)) THEN 1::int ELSE 0::int END AS matchinstagenarrow, ==Xunjie's Notes== Xunjie Zheng wrote "Notes on Estimation of Venture Model", which is in the project folder. Note on that doc:*Startup-Specific Variables: **VE adds executives round after round, so firms with more rounds will have more executives. We should only use Founders and whether or not they are serial from the executive measures.**We should be using patents here?**This appears ok in section 4 but not in section 1**It somewhat repeats in section 5.1**PC Total Investor suffers from similar issues*The dataset might not be informational...**Interaction terms related to VC Exp could have over 70% of zeros*Same city indicator? Also, log distance. Transformation is awkward.*We may want to redefine PC Rank so that the higher its value the higher the rank of the city Potential news vars:*FracOfDealsInSector*Patent Measure? Imprecisely estimated...  Data:*748 -- real matches*Cap on market size?*5-10 on each side*market size cutoff*firmcat - check it!*Market size below 20-30. Over 100 markets. Should be fine.*Single node - 80 Cores ===Discussion Points=== Discuss normalization: Distance is standardized to have zero mean and unit variance with respect to the whole dataset. PC Rank is normalized to be between 0 and 1 with respect to the whole dataset. Other variables are normalized to be between 0 and 1 with respect to each matching market. See Table 1 for summary statistics for realized matches before data transformation. See Table 2 for summary statistics for realized matches after data transformation. Discuss: In general, the average market complementarity in Table 8, the average observed market production in Table 9, and the average observed market complementarity in Table 10 should be the highest for the original market, then after removing the worst VC, then after removing the mediocre VC, and then after removing the best VC. If the latter three counterfactual values are similar, it is due to the small magnitude of the coefficient compared to other coefficients in the model. The counterfactual values in Models 3 and 5 are higher than the original one in Table 8, it is because there is a dominant negative coefficient in the model. Also, the large standard deviation of unobserved complementarity makes unobserved complementarity and so is the whole complementarity of some matches to be large and negative. After one firm is removed, the number of total matches in the optimal assignment decreases by 1 so that the match with large and negative unobserved complementarity is dropped. However, since the observed production or observed complementarity of the same match may not be negative, such case only appears in Table 8. To be checked:*VC Exp is “matchprevindu20” in the codebook, which is defined as “Matched VCs prior experience investing in companies (i.e., count of companies) in the same pccode20 as the PortCo”. There might be a mistake in constructing this variable. The VC Exp for counterfactual matches are greater than or equal to the value for realized matches.  ===Tables in the paper=== Tables:1 & 2 Summary stats (reg, norm)*Distance normalization is strange. Use logs? *PC RANK should be non-linear?*PC investor can be standardized - first round (of interest), or av. per round? 3 Structural Estimation Results*Model 6 has two unexpected signs*rhos are unobserved complementarity correlations and sigma is its std. dev. *Why not the main effects? Interpretation of interactions is problematic. 4 Change in production with respect to one standard deviation of the (interaction) variable 5 Change in production with respect to one standard deviation of one variable in the interaction term while setting the other variable at 0.5 6 Number of zeros in matches (all vs. realized). Seems to indicate data issues??? 7 Correlation between (two) firm-specific variables and (three) portco-specific variables in realized matches 8 Counterfactual average market complementarity, 9 Counterfactual average observed market production, 10 Counterfactual average observed market complementarity*VC Tenure is probably the wrong measure... Presumably, funds are alive because they are in the market... Also, inverted U. Stage drift. Etc.*Investment? *Currently removing by tenure and experience (in thirds)*Should do: GSVC, CVC, non-market VC? 11 - 14 - IPO and M&A and both among '''unmatched startups'''*Exitvalue. M&A suffers from issues. Disclosed value M&A would be better?*Worse VC IPO/M&A likely a better but maybe non-temporal as implemented. 15 Geog dist. *Why 748 matches? 16-19 Posterior exit rates. *VC tenure looks problematic again. Also M&A issues with firesales. Tables from Section 5 - Results with New Variables:*Check stage fit*Check co-investors is in the deal. ===Other Notes on Xunjie's Work=== The estimation strategy is a two-step simulated method of moments. The solver is "adaptive_de_rand_1 bin_radius_limited" in theJulia package "BlackBoxOptim.jl", which executes Differential Evolution algorithm. Julia code:*https://github.com/robertfeldt/BlackBoxOptim.jl (support parallel CPU) ==Previous Work==

====Rebuilding Marcos==== Marcos starts with a dataset of reals with a single synthetic, and then constructs a dataset of reals with all synthetics (in the same year and code20).  Table 1 gives some LPMs using two sets of variables with and without VC-yearmet fixed effects. These are replicated in the new do file. In order to get something close to Marcos's reported numbers, I create a one-to-one variable so that each real match has only a single synthetic match. This gives about 60k observations as compared with Marcos's 64K (and as opposed to 445k for the full sample). The coefficients are very close to those in Table 1. There are some caveats, however. Marcos is using:*Amounts in billions (as am I) without taking logs (of 1+x)*Firmid x year (which he refers to as VC x yearmet) fixed effects, as opposed to year (i.e., dealminroundyear) x pccode20 fixed effects, which correctly define a market*No restrictions on timing Table 5 gives some LPMs before and after a Lasso. The hqdist variable was first transformed so that hqdist = hqdist/1000. Note that the matchhqdist variable is bimodal. Matchbodist is also bimodal but not as strongly. The second spike in the distribution is just over 4000km, which is the arc distance from San Francisco to Boston (4335km [https://www.distance.to/Boston/San-Francisco]) Again the data is just a single synthetic for each real. In this analysis, Marcos also clusters the standard errors at the year level, but does not use any fixed effects. The key regressions labels in the pdf aresomewhat misleading. The margin command reports only the underlying covariates not the interactions (unless you specifically generate the variables). An analysis of just the underlying variables without the interactions would have produced markedly different margins! The margins in table 6 column 1 of the pdf are coming from the following:  PDF -> source -------------------------------------- hdqist -> c.hqdist##c.hqdist sumprevsameindu20 -> c.sumprevsameindu20##c.sumprevsameindu20 serials -> c.serials##c.numprevportco numprevportcos -> c.patentsprevc##c.numprevportco firmtenure -> c.serials##c.firmtenure patentsprevc -> c.patentsprevc##c.firmtenure Note that STATA uses ## to report both main effects for each variable as well as an interaction, so c.hqdist##c.hqdist reports both hqdist and hqdist^2, while c.serials##c.numprevportco reports serials, numprevportco, and serials*numprevportco. Variables are omitted when duplicated as in c.serials##c.numprevportco and c.patentsprevc##c.numprevportco, which both report numprevportco. We don't get the same lasso results as Markus: Variable MarcosLasso NewLasso ----------------------------- hdqist yes yes sumprevsameindu20 yes yes serials yes no numprevportcos yes no firmtenure yes yes patentsprevc no no But Marcos's spec isn't very grounded. He clusters standard errors at the year level but uses no fixed effects. We want to know what goes on inside markets, implying market-level fixed effects. He believes that "Since non-match specific variables are not used in the structural model, we have to interact VC or Startup specific variables." I'm not sure that this is correct. He goes on to say that "Therefore, the main specification is one which every match-specific variable has a quadratic interaction, and startup and VC variables are interacted with each other. Also, we exclude industry code from the model because it is a discrete variable, andwe transform VC founding year to VC tenure, which subtracts the former with year of match."  Industry certainly won't matter with market fixed effects. Marcos also used numprevportco as if it was purely a VC variable, rather than being closer to a match specific variable.  I tried Marcos's approach using all of the possible variables (old and new) but always and only using firmtenurel as a VC interaction variable (as firmportcosl is used to pick the real from the list of potential reals, and as firmapportione~ml is correlated with firmportcosl). I will also only use pccityoverallr~1l as the PortCo interaction variable, as that's the only PortCo variable that survives to significance. The result was: . margins, dydx(*) post Average marginal effects Number of obs = 381,882 Model VCE : Robust Expression : Linear prediction, predict() dy/dx w.r.t. : pccityoverallrankm1l firmtenurel firmportcosl matchprevindu20l matchbodistl matchinstagenarrow matchcity matchstate -------------------------------------------------------------------------------------- | Delta-method | dy/dx Std. Err. t P>|t| [95% Conf. Interval] ---------------------+---------------------------------------------------------------- pccityoverallrankm1l | .0055706 .0002035 27.38 0.000 .0051718 .0059694 firmtenurel | .0059353 .0005165 11.49 0.000 .0049229 .0069477 firmportcosl | .0052155 .0004399 11.86 0.000 .0043532 .0060777 matchprevindu20l | -.0536725 .0007413 -72.41 0.000 -.0551254 -.0522196 matchbodistl | -.0106516 .0003413 -31.21 0.000 -.0113205 -.0099826 matchinstagenarrow | .0057086 .0007494 7.62 0.000 .0042398 .0071774 matchcity | .0684326 .0041129 16.64 0.000 .0603715 .0764937 matchstate | .0436431 .0015343 28.45 0.000 .040636 .0466503 -------------------------------------------------------------------------------------- Finally, collapse the dataset by summing realmatch and produce a histogram and some analysis.

==Previous Work (for reference)MATLAB Estimator==

===Matlab MATLAB Code===

[[Abhijit Brahme (Work Log)]] contains his notes on working with the Matlab MATLAB code. There is a seperate page here: [[Estimating Unobserved Complementarities between Entrepreneurs and Venture Capitalists Matlab Code]].